[LLVMdev] RFC: Atomics.h
jrk at csail.mit.edu
Thu May 28 18:03:32 PDT 2009
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.
> LLVM Developers mailing list
> LLVM... at cs.uiuc.edu http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
More information about the llvm-dev