On May 17, 2009, at 12:32 PM, Chris Lattner wrote:> Owen, I would really rather that you didn't take this path. Threading > support in LLVM should always be optional: it should be possible to > use LLVM on systems where we don't have support for threading > operations. Indeed, some systems don't support threads!I'm not trying to make it required. I had provided threads-disabled versions of all the operations.> Given that, I think it makes sense to start out the atomics > operations very simple: just make them work for compilers that support > GCC 4.2's atomics. Since things will be changing quickly initially, > this makes it easy to prototype and build things out, and this also > avoids pulling in an external library with a (compatible but) > different license. > > In practice, I think a huge chunk of the community will be served when > LLVM supports GCC 4.2 atomics + a windows implementation. I don't see > a reason to make things any more complex than that. Since llvm-gcc > supports atomics, someone doing development on a supported > architecture can just build llvm-gcc single threaded, which provides > them with a compiler that supports atomics on their platform.After thinking about this some more, I think you're right. Trying to support every platform anyone cares about is rapidly becoming a nightmare. Setting GCC4.2 as a baseline requirement (and presumably providing a Windows implementation as well) is probably a good way to get this back to a sane amount of stuff to support. --Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4463 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090517/94b7c3c0/attachment.bin>
In the current trunk, System/Atomic.[h,cpp] define void llvm::sys::MemoryFence(). This conflicts with the MemoryFence macro in <windows.h> and (since it's a preprocessor macro, and not a scoped function definition) causes the sys::MemoryFence definition on Atomic.cpp:23 to explode, as it's nonsensically expanded to a cl intrinsic (_mm_mfence). This breaks the Visual Studio build. The trivial fix is to #undef MemoryFence immediately after including <windows.h>, since it's clearly assumed not to exist. A deeper and safer fix might consider avoiding a name conflict with a core system macro on a widely used platform. On May 17, 1:20 pm, Owen Anderson <resis... at mac.com> wrote:> On May 17, 2009, at 12:32 PM, Chris Lattner wrote: > > > Owen, I would really rather that you didn't take this path. Threading > > support in LLVM should always be optional: it should be possible to > > use LLVM on systems where we don't have support for threading > > operations. Indeed, some systems don't support threads! > > I'm not trying to make it required. I had provided threads-disabled > versions of all the operations. > > > Given that, I think it makes sense to start out the atomics > > operations very simple: just make them work for compilers that support > > GCC 4.2's atomics. Since things will be changing quickly initially, > > this makes it easy to prototype and build things out, and this also > > avoids pulling in an external library with a (compatible but) > > different license. > > > In practice, I think a huge chunk of the community will be served when > > LLVM supports GCC 4.2 atomics + a windows implementation. I don't see > > a reason to make things any more complex than that. Since llvm-gcc > > supports atomics, someone doing development on a supported > > architecture can just build llvm-gcc single threaded, which provides > > them with a compiler that supports atomics on their platform. > > After thinking about this some more, I think you're right. Trying to > support every platform anyone cares about is rapidly becoming a > nightmare. Setting GCC4.2 as a baseline requirement (and presumably > providing a Windows implementation as well) is probably a good way to > get this back to a sane amount of stuff to support. > > --Owen > > smime.p7s > 5KViewDownload > > _______________________________________________ > LLVM Developers mailing list > LLVM... at cs.uiuc.edu http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On May 28, 2009, at 6:03 PM, Jonathan Ragan-Kelley wrote:> In the current trunk, System/Atomic.[h,cpp] define void > llvm::sys::MemoryFence(). This conflicts with the MemoryFence macro in > <windows.h> and (since it's a preprocessor macro, and not a scoped > function definition) causes the sys::MemoryFence definition on > Atomic.cpp:23 to explode, as it's nonsensically expanded to a cl > intrinsic (_mm_mfence). This breaks the Visual Studio build. > > The trivial fix is to #undef MemoryFence immediately after including > <windows.h>, since it's clearly assumed not to exist. A deeper and > safer fix might consider avoiding a name conflict with a core system > macro on a widely used platform.Wait, it defines MemoryFence() AND MemoryBarrier()?? Sheesh, they had to take all the reasonable names. :-/ --Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2620 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090528/8202b1f7/attachment.bin>