[LLVMdev] RFC: Atomics.h

[Jonathan Ragan-Kelley]

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