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

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

Alistair

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).

Dan

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.