[LLVMdev] Proposal for a new LLVM concurrency memory model
jyasskin at google.com
Tue Apr 27 13:25:17 PDT 2010
On Tue, Apr 27, 2010 at 12:00 PM, David Greene <dag at cray.com> wrote:
> On Tuesday 27 April 2010 13:56:05 Renato Golin wrote:
>> 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. ;)
> I suspect not. :) I still mean within the compiler, just at a higher
> level program abstraction; a higher-level IR.
> Concurrent languages can help, but history shows that it's tough to
> get them accepted. HPF is a four-letter word here. ;) Now CAF,
> on the other hand...
> Maybe this trend will change with the new silicon constraints, but I'm
> skeptical. We'll be programming in C, C++ and Fortran for a long time.
> The compiler is going to have to find parallelism and the user is
> going to have to help with directives.
I think we're diverging from the memory model now... David, I think
you're happy with the current proposal to define atomics as
non-tearing even for vector operands (acknowledging that the backend
may fail to codegen operands that are too big)? Did I miss any other
suggestions you made?
More information about the llvm-dev