[LLVMdev] Proposal for a new LLVM concurrency memory model

Jeffrey Yasskin jyasskin at google.com
Tue Apr 27 14:12:36 PDT 2010


On Mon, Apr 26, 2010 at 2:26 PM, Dan Gohman <gohman at apple.com> wrote:
>
> On Apr 26, 2010, at 1:15 PM, Alistair Lynn wrote:
>
>> Hi David-
>>
>> On 26 Apr 2010, at 21:05, David Greene wrote:
>>
>>> What's a "trap" and "trap value?"  Is it some C++0X or Java thing?
>>> It needs to be defined.
>>
>> See LangRef.html
>
> Yes; it was just added 4 days ago, for an unrelated purpose.  It's an
> interesting concept which on the surface seems to be a good fit, though
> there are some complicating issues.
>
> Here's one:
>
> In the "load widening" section of the proposed memory model, if there's
> a race condition on the high bits of a widened load, but the high bits
> are never observed, the low bits should remain defined. However, that's
> not how the current trap concept works (yet).

I've changed racy loads from returning trap values to returning undef.
I think that's ok for Boehm's switch optimization
(http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/why_undef.html) given
that undef values can appear different on each use, but there could
easily be other optimizations we haven't thought of that it breaks. On
the other hand, returning trap values would break partial loads, as
you pointed out.

I suspect we'll be able to change this again after accepting the
memory model if it turns out to impede optimizations.




More information about the llvm-dev mailing list