[LLVMdev] Proposal for a new LLVM concurrency memory model

[David Greene]

On Tuesday 27 April 2010 12:16:26 Renato Golin wrote:

> I'm not against enhancing the compiler to that point, I just think
> that you're digging too deep and Balrog might show up unexpectedly.
> Thread issues can be daunting by themselves, automatically creating
> threaded code is a recipe to disaster, IMHO.

Eventually all compilers are going to have to create threads.  The
architecture roadmap demands it.

> > Again, my vote is to define vector atomics as respecting atomicity across
> > elements and make it the compiler's and user's job to know when it can
> > use them.
>
> By means of #pragmas?

That's one way.  OpenMP is the standard API to control this but
vendors have tons of extensions and their own directives to tell
the compiler what is or is not legal.  IMHO, LLVM is the wrong
place to deal with these.  It should be done at a higher level.
It _can_ be done at the LLVM IR level, but much less conveniently.

                         -Dave