llvm dev - Apr 2010 - [LLVMdev] Proposal for a new LLVM concurrency memory model

On 27 April 2010 17:28, David Greene <dag at cray.com>
wrote:
> The compiler integrates into a comprehensive programming environment.
> It has to know what the environment provides and uses.  That _is_ very much
> the compiler's responsibility.
I agree the compilers should know about threads, but enough to work
around the issues and not start creating threads the user didn't ask
for.

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.

> 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?


cheers,
--renato

http://systemcall.org/

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

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

On Tuesday 27 April 2010 13:16:14 David Greene wrote:
> 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.
And it's not the disaster you fear.  It's much easier for the compiler
to reason about threads it creates.  It gets to control the model.

Lots of compilers have been doing this for years.

                           -Dave

On 27 April 2010 19:16, David Greene <dag at cray.com>
wrote:
> 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.
Now I agree with you, completely. ;)

It is important, it is the future, but it is in the library/language
definition space that the solution will be more elegant.

Like functional languages, HPF, openMPI, Scala having intrinsic
message passing or openMP constructs, the compiler has much more
freedom to guess and do the right thing (tm).


cheers,
--renato

http://systemcall.org/

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm