[LLVMdev] Proposal for a new LLVM concurrency memory model

[Jeffrey Yasskin]

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?

Thanks,
Jeffrey