similar to: [LLVMdev] llvm.atomic.barrier implementation

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) @@

On Feb 15, 2008, at 2:29 PM, Andrew Lenharth wrote: > 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. GCC 4.2 compiles this to a no-op on x86: void foo() { __sync_synchronize(); } Are you seeing different behavior?

On Feb 15, 2008, at 2:29 PM, Andrew Lenharth wrote: > 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. Thanks for tackling this Andrew. Please prepare a patch for LangRef.html that explains what this thing does :). What

Hi all, I'm trying to implement llvm.memory.barrier on PowerPC. I've modelled my patch (attached) on the implementation in X86, but when I try and compile my test file (also attached) with llc I get the error "Cannot yet select: 0x10fa4ad0: ch = MemBarrier 0x10fa4828, 0x10fa4c68, 0x10fa4be0, 0x10fa4be0, 0x10fa4be0, 0x10fa4be0". This presumably means my "membarrier"

Thanks for the info. My impression is that __sync_synchronize takes no arguments and is the memory barrier, i.e., "llvm.memory.barrier(i1 true,i1 true,i1 true,i1 true,i1 true)". Is that right? I would like a little finer control to express just a write barrier (st-st) or a read barrier. -- Mon Ping On Sep 17, 2008, at 5:50 AM, Andrew Lenharth wrote: > On Tue, Sep 16,

Dale Johannesen wrote: > On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: > > I'm trying to implement llvm.memory.barrier on PowerPC. I've > > modelled my patch (attached) on the implementation in X86, but > > when I try and compile my test file (also attached) with llc I > > get the error "Cannot yet select: 0x10fa4ad0: ch = MemBarrier > >

No, I don't. Cheers, Gary Dale Johannesen wrote: > This looks OK to check in, do you have write access? > > On Aug 21, 2008, at 6:38 AMPDT, Gary Benson wrote: > > >Dale Johannesen wrote: > >>On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: > >>>I'm trying to implement llvm.memory.barrier on PowerPC. I've > >>>modelled my patch

Hi all, I want to implement llvm.memory.barrier on PowerPC. The implementation would be the single instruction "sync", but currently it's defined with: setOperationAction(ISD::MEMBARRIER, MVT::Other, Expand) in lib/Target/PowerPC/PPCISelLowering.cpp, which causes it to be a noop. I replaced the "Expand" with "Legal" in the hope I'd get an error message

On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: > Hi all, > > I'm trying to implement llvm.memory.barrier on PowerPC. I've modelled > my patch (attached) on the implementation in X86, but when I try and > compile my test file (also attached) with llc I get the error "Cannot > yet select: 0x10fa4ad0: ch = MemBarrier 0x10fa4828, 0x10fa4c68, > 0x10fa4be0,

This looks OK to check in, do you have write access? On Aug 21, 2008, at 6:38 AMPDT, Gary Benson wrote: > Dale Johannesen wrote: >> On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: >>> I'm trying to implement llvm.memory.barrier on PowerPC. I've >>> modelled my patch (attached) on the implementation in X86, but >>> when I try and compile my test

Mon Ping Wang wrote: > Thanks for the info. My impression is that __sync_synchronize takes > no arguments and is the memory barrier, i.e., > "llvm.memory.barrier(i1 true,i1 true,i1 true,i1 true,i1 true)". Is > that right? That's my understanding as well. > I would like a little finer control to express just a > write barrier (st-st) or a read barrier.

Hi Luke, What you say makes sense but I'm not sure it is a good way to go. If we are using a gcc function name __sync_synchronize, I generally feel like we should support it with exactly the same signature and not try to extend it. Otherwise, it might lead to some confusion in the future unless they also plan to extend it the same way. -- Mon Ping On Sep 17, 2008, at 1:14 PM,

On Tue, Sep 16, 2008 at 5:42 PM, Mon Ping Wang <wangmp at apple.com> wrote: > > I would like access to LLVM memory barrier instruction as a built-in > from clang, which means that I need a name for it. In gcc, I see names > like __builtin_ia32_mfence but those refers to X86 SSE instruction > that we support. I don't see a gcc name that has the same semantics > as our

I would like access to LLVM memory barrier instruction as a built-in from clang, which means that I need a name for it. In gcc, I see names like __builtin_ia32_mfence but those refers to X86 SSE instruction that we support. I don't see a gcc name that has the same semantics as our barrier instruction. For a name, I was thinking of __builtin_memory_barrier or

Thanks, I am now working on compiling up VMKit. When compiling VMKit in my up-to-date svn checkout I get several error messages on missing members of the class 'llvm::Type': PNetLib.cpp: In function ‘void decapsulePrimitive(n3::VMObject*, const llvm::Type*, std::vector<llvm::GenericValue, std::allocator<llvm::GenericValue> >&)’: PNetLib.cpp:694: error: ‘Int1Ty’ is not a

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,

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:

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 Sat, 2005-02-26 at 22:34 -0600, Chris Lattner wrote: > On Sat, 26 Feb 2005, Tanu Sharma wrote: > > > Thanks for the reply :-) > > I am actually looking for ways to determine "size" of code segment when the program is in native code. > > Any suggestions to do that ? > > Compile it with llvm to a native .o or .exe file, then run 'size' on it? >