similar to: [LLVMdev] A question about gcWriter

> On Oct 26, 2013, at 12:37 AM, Michael Lewis <don.apoch at gmail.com> wrote: > > I'm also highly interested in relocating-GC support from LLVM. Up until now my GC implementation has been non-relocating which is obviously kind of a bummer given that it inhibits certain classes of memory allocation/deallocation tricks. You can implement a copying GC (what the kids these days

Actually I tried ModulePass. It works exactly as what I expect.But I found another problem. In ModulePass, it not only collects the functions I create, it also treat some system function such as 'printf' as a function. I do not if I does something wrong. The codes I use is as follows: virtual bool runOnModule(Module &M) { for (Module::iterator b = M.begin(), be = M.end(); b !=

Gordon Henriksen wrote: > On 2007-09-15, at 23:55, Talin wrote: > >> Gordon Henriksen wrote: >> >>> Can you be more specific the algorithm for which you need type >>> metadata in a write barrier? No algorithms I am aware of perform any >>> tracing from a write barrier. >> >> This one does: >> >>

On 2007-09-15, at 23:55, Talin wrote: > Gordon Henriksen wrote: > >> Can you be more specific the algorithm for which you need type >> metadata in a write barrier? No algorithms I am aware of perform >> any tracing from a write barrier. > > This one does: > > http://citeseer.ist.psu.edu/cache/papers/cs2/442/ >

Gordon Henriksen wrote: > Can you be more specific the algorithm for which you need type > metadata in a write barrier? No algorithms I am aware of perform any > tracing from a write barrier. > This one does: http://citeseer.ist.psu.edu/cache/papers/cs2/442/http:zSzzSzwww.cs.technion.ac.ilzSz~erezzSzPaperszSzms-sliding-views.pdf/an-on-the-fly.pdf > Write barriers are

I'd like to share some code with anyone who is interested. A while back I started working on the problem of implementing a garbage collector using the LLVM primitives. While I managed to accomplish a fair bit in this direction, I eventually realized that it was distracting me from my main goal, which is implementing a compiler for a strongly-typed language of my own design. In other

I'm also highly interested in relocating-GC support from LLVM. Up until now my GC implementation has been non-relocating which is obviously kind of a bummer given that it inhibits certain classes of memory allocation/deallocation tricks. I wrote up a bunch of my findings on the implementation of my GC here: https://code.google.com/p/epoch-language/wiki/GarbageCollectionScheme Frankly I

The Asterisk Development Team has announced security releases for Asterisk branches 1.4, 1.6.1, 1.6.2, and 1.8. The available security releases are released as versions 1.4.39.2, 1.6.1.22, 1.6.2.16.2, and 1.8.2.4. These releases are available for immediate download at http://downloads.asterisk.org/pub/telephony/asterisk/releases The releases of Asterisk 1.4.39.2, 1.6.1.22, 1.6.2.16.2, and

The Asterisk Development Team has announced security releases for Asterisk branches 1.4, 1.6.1, 1.6.2, and 1.8. The available security releases are released as versions 1.4.39.2, 1.6.1.22, 1.6.2.16.2, and 1.8.2.4. These releases are available for immediate download at http://downloads.asterisk.org/pub/telephony/asterisk/releases The releases of Asterisk 1.4.39.2, 1.6.1.22, 1.6.2.16.2, and

On Mon, Oct 7, 2013 at 4:22 PM, Filip Pizlo <fpizlo at apple.com> wrote: > > > On Oct 7, 2013, at 3:49 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > > > On Wed, Sep 25, 2013 at 5:50 PM, Filip Pizlo <fpizlo at apple.com> wrote: >> >> Hi all, >> >> TBAA on loads and stores is super useful for conveying high-level type

Hi Eli and Others In response to your feedback, I have taken care of all your review comments - I removed clangOMP.a and moved the implementation of "class OmpPragmaHandler" to "clangLex.a". The attached zipped file - namely - 'OpenMP_support_in_Clang.tar.gz' contains all the implemented "patches" along with *newly* added source files. Another attached text

On Wed, Sep 25, 2013 at 5:50 PM, Filip Pizlo <fpizlo at apple.com> wrote: > Hi all, > > TBAA on loads and stores is super useful for conveying high-level type > knowledge to LLVM transformations. But often translating a high-level > language into LLVM IR will result in runtime calls that are known at the > high level to only affect (either by reading or by writing) some

On Oct 7, 2013, at 3:49 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > > On Wed, Sep 25, 2013 at 5:50 PM, Filip Pizlo <fpizlo at apple.com> wrote: > Hi all, > > TBAA on loads and stores is super useful for conveying high-level type knowledge to LLVM transformations. But often translating a high-level language into LLVM IR will result in runtime calls

On Fri, 22 Oct 2004, Marc Ordinas i Llopis wrote: > Hi everybody, Hi! > I'm currently looking at LLVM as a possible back-end to a dynamic > programming system (in the tradition of Smalltalk) we are developing. I Very cool! > have read most of the llvmdev archives, and I'm aware that some things > are 'planned' but not implemented yet. We are willing to

> -----Original Message----- > From: David Neto [mailto:dneto.llvm at gmail.com] > Sent: Tuesday, December 07, 2010 1:03 PM > To: Villmow, Micah > Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > Subject: Re: [cfe-dev] [LLVMdev] OpenCL support > > On Mon, Dec 6, 2010 at 6:16 PM, Villmow, Micah <Micah.Villmow at amd.com> > wrote: > >> -----Original

Hi all, TBAA on loads and stores is super useful for conveying high-level type knowledge to LLVM transformations. But often translating a high-level language into LLVM IR will result in runtime calls that are known at the high level to only affect (either by reading or by writing) some restricted subset of the heap. These aren't read-only calls; that is often too strong of a guarantee. A

On Mon, Oct 7, 2013 at 7:34 PM, Filip Pizlo <fpizlo at apple.com> wrote: > I think we’re talking cross-purposes at this point. Let me try to step > back and concisely restate what I’m trying to do: > > - I am writing a frontend for a high-level language and I emit LLVM IR. > - I control the TBAA tree. I don’t use it to express the high-level > language’s types, since

On Tue, Oct 8, 2013 at 12:45 PM, Manman Ren <manman.ren at gmail.com> wrote: > > TBAA MDNodes should describe the type hierarchy (with struct-path aware > TBAA, it is a type DAG). > It sounds okay to me to add !tbaa.call to function calls to describe which > fields of the type system the call is touching. > I agree wholeheartedly :). However, that's not what is being

On 07/29/2015 09:32 AM, Reid Kleckner wrote: > On Tue, Jul 28, 2015 at 10:58 AM, Philip Reames > <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: > > Having read through the proposal, I feel like I missing some of > the background to understand the problem you're trying to solve. > > My mental model is that construction

I found myself wanting a "scheduling barrier" in LLVM. In my specific circumstances I only want it to mean that TargetInstrInfoImpl::isSchedulingBoundary() would return true. I added SchedulingBarrier to MCID in MCInstrDesc.h and pushed it through TD attributes down to isSchedulingBoundary(). Is this something of general interest, or is there another mechanism for implementing