similar to: [LLVMdev] atomics

On 2/15/08, Andrew Lenharth <andrewl at lenharth.org> wrote: > I'll take a hack at the front end support for > __sync_synchronize after this goes in. This is the gcc side of the patch. Index: gcc/llvm-convert.cpp =================================================================== --- gcc/llvm-convert.cpp (revision 46956) +++ gcc/llvm-convert.cpp (working copy) @@

Attached is the target independent llvm.atomic.barrier support, as well as alpha and x86 (sse2) support. This matches Chandler's definitions, and the LangRef patch will just restore that. Non-sse2 barrier will be needed, I think it is "lock; mov %esp, %esp", but I'm not sure. Any objections? I'll take a hack at the front end support for __sync_synchronize after this

On 7/9/07, Andrew Lenharth <andrewl at lenharth.org> wrote: > Poor alpha, no code examples or entries in your tables. But that said, it uses a load-locked, store-conditional and has various memory barriers which are sufficient to implement all your proposal. Andrew > On 7/9/07, Chandler Carruth <chandlerc at gmail.com> wrote: > > Hello, > > > > After a fair

On 11/30/06, Andrew Lenharth <andrewl at lenharth.org> wrote: > The llvm_ostreams, which you take the address of go out of scope very > quickly, and are only stored by address in the bytecode writer, thus > the writers have a pointer to a stack allocated object they are to > write to. This crashes. The attached version leaks :-) It is a work around. If I understand correctly,

I just looked over your diff and it would seem to me that additional changes would be needed to be done to some of the LLVM-IR -> DAG stuff to make things fully functional (this could be a bit of supposition on my part since I do not fully understand all of the code). --- On Sun, 8/2/09, Andrew Lenharth <andrewl at lenharth.org> wrote: > From: Andrew Lenharth <andrewl at

On Sun, Aug 2, 2009 at 6:09 PM, Carter Cheng<carter_cheng at yahoo.com> wrote: > I just looked over your diff and it would seem to me that additional changes would be needed to be done to some of the LLVM-IR -> DAG stuff to make things fully functional (this could be a bit of supposition on my part since I do not fully understand all of the code). Code generation actually was

On Wed, Jul 14, 2010 at 10:54 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Jul 14, 2010 at 8:33 AM, Andrew Lenharth <andrewl at lenharth.org> wrote: >> On Wed, Jul 14, 2010 at 10:26 AM, Eli Friedman <eli.friedman at gmail.com> wrote: >>> On Wed, Jul 14, 2010 at 3:20 AM, Torvald Riegel >>> <torvald at se.inf.tu-dresden.de> wrote:

does that mean .o generated with gcc (.c -> .s and .s -> .o) will not contain llvm ir? i meant, final kernel bitcode ir arch independent and can be JIT with any arch-specific backend. Is it not the case? thanks, ashish On Sat, Sep 27, 2008 at 10:43 PM, Andrew Lenharth <andrewl at lenharth.org> wrote: > On Sat, Sep 27, 2008 at 8:08 PM, Ashish Bijlani > <ashish.bijlani at

Its good to see that a feature of this nature would be useful to a whole range of people, I wasn't aware of that. On 9 June 2010 22:40, Andrew Lenharth <andrewl at lenharth.org> wrote: > My argument amounts to express side tables as side tables in the IR > rather than as an ordering on globals.  I think that would simplify > the backend (a side table is something you discover

I updated the latest "poolalloc" code and the problem seems to have been fixed. However, I am still having problem of running "poolalloc". After compilation finished, there are several dynamic libraries created (libpoolalloc_rt.so, libpoolalloc_fl_rt.so and LLVMDataStructure.so). I was not sure which one I should use so I just tried all of them with "opt -load".

On 21 September 2010 18:39, Andrew Lenharth <andrewl at lenharth.org> wrote: > Type names don't have meaning.  If you want this not to happen, you > can generate a different opaque type for each type in your language to > prevent merging. Hi Andrew, Why create opaque types to avoid something that should be taken from granted (in a said "type-safe" representation)? I

DSA should be current against head, but poolalloc isn't. I've changed DSA a bit so it may not compile with poolalloc as is. I haven't had time to tackle updating poolalloc (either to head or to the dsa changes). If you want the version from the paper, try checking out llvm 1.8 or 1.9 and a dsa from around then. The dsa as used on the linux kernel and in the OS work is in a branch

On Wednesday 14 July 2010 17:57:26 Andrew Lenharth wrote: > On Wed, Jul 14, 2010 at 10:54 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > > On Wed, Jul 14, 2010 at 8:33 AM, Andrew Lenharth <andrewl at lenharth.org> wrote: > >> On Wed, Jul 14, 2010 at 10:26 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > >> Is alignment on a field

On Wed, Jul 14, 2010 at 10:26 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Jul 14, 2010 at 3:20 AM, Torvald Riegel > <torvald at se.inf.tu-dresden.de> wrote: >> On Tuesday 13 July 2010 19:48:25 you wrote: >>> On Tue, Jul 13, 2010 at 10:09 AM, Torvald Riegel >>> > I thought that the layout of structs was supposed to be preserved (wrong

Poor alpha, no code examples or entries in your tables. Andrew On 7/9/07, Chandler Carruth <chandlerc at gmail.com> wrote: > Hello, > > After a fair amount of research and work, I have put together a > concrete proposal for LLVM representations of atomic operations and > synchronization constructs. These aim to provide the minimal > functionality in the IR for

Hello Kapil, I have implemented a static profiler for LLVM as a google summer of code project in 2009. I wrote it for the 2.4 branch, but the implementation never made into the tree. I have recently ported it to LLVM 2.8, but I haven't tested it. You can take a look at the code from: http://homepages.dcc.ufmg.br/~rimsa/tools/stprof-llvm.patch The implementation is based on Wu's

On Thu, Jun 10, 2010 at 11:34 AM, David Terei <davidterei at gmail.com> wrote: > Its good to see that a feature of this nature would be useful to a > whole range of people, I wasn't aware of that. > > On 9 June 2010 22:40, Andrew Lenharth <andrewl at lenharth.org> wrote: >> My argument amounts to express side tables as side tables in the IR >> rather than as

On Sat, May 14, 2005 at 02:18:26AM +0200, Stefan Strasser wrote: > in case you're interested in having llvm in debian sarge: it was > removed today. I don't know why, but you might want to find out > because sarge is in freeze phase for release next month. Possibly because of these: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=llvm I addressed the first one and fixed it in

in case you're interested in having llvm in debian sarge: it was removed today. I don't know why, but you might want to find out because sarge is in freeze phase for release next month. regards, -- Stefan Strasser

Haifeng He wrote: > I updated the latest "poolalloc" code and the problem seems to have been fixed. > However, I am still having problem of running "poolalloc". > > After compilation finished, there are several dynamic libraries > created (libpoolalloc_rt.so, libpoolalloc_fl_rt.so and > LLVMDataStructure.so). I was not sure which one I should use so I just