[llvm-commits] [llvm] r135624 - /llvm/trunk/docs/LangRef.html

[Eli Friedman]

On Wed, Jul 20, 2011 at 4:44 PM, Dan Gohman <gohman at apple.com> wrote:
>> +</ul>
>> +
>> +<p>Given that definition, <var>R<sub>byte</sub></var> is defined as follows:
>> +<ul>
>> +  <li>If there is no write to the same byte that happens before
>> +    <var>R<sub>byte</sub></var>, <var>R<sub>byte</sub></var> returns
>> +    <tt>undef</tt> for that byte.
>
> How do static initializers fit into this?

An initializer acts like a write that happens before any read; I'll
add something explicit.

>> +  <li>If <var>R<sub>byte</sub></var> may see exactly one write,
>> +      <var>R<sub>byte</sub></var> returns the value written by that
>> +      write.</li>
>
> What if there's exactly one write, but the read also may-see the memory
> before any writes happen?

That's supposed to be covered by "If there is no write to the same
byte that happens before..."

>> +  <li>If <var>R<sub>byte</sub></var> and all the writes it may see are
>> +      atomic, it chooses one of those writes and returns it value.
>> +      Given any two bytes in a given read <var>R</var>, if the set of
>> +      writes <var>R<sub>byte</sub></var> may see is the same as the set
>> +      of writes another byte may see, they will both choose the same write.
>
> What if there are two multi-byte reads, and both their may-see sets contain
> only atomic writes, but the sets are different? Can bytes from atomic
> multi-byte writes be interleaved in this case?

I'll try to make this clearer.  The intent is the obvious semantics
for multiple unordered atomic writes followed by an atomic read, but
it gets a little complicated because you can mix atomic writes of
differing sizes.

> Also, does this rule apply even when R is non-atomic? Is it intended to
> require that all multi-byte reads must read all of their bytes simultaneously?

No, it doesn't apply when R is not atomic ("if Rbyte and... are
atomic"); I suppose that could be made clearer.

>> +  <li>Otherwise <var>R<sub>byte</sub></var> returns <tt>undef</tt>.</li>
>> +</ul>
>> +
>> +<p><var>R</var> returns the value composed of the series of bytes it read.
>> +This implies that some bytes within the value may be <tt>undef</tt>
>> +<b>without</b> the entire value being <tt>undef</tt>. Note that this only
>> +defines the semantics of the operation; it doesn't mean that targets will
>> +emit more than one instruction to read the series of bytes.</p>
>> +
>> +<p>Note that in cases where none of the atomic intrinsics are used, this model
>> +places only one restriction on IR transformations on top of what is required
>> +for single-threaded execution: introducing a store to a byte which might not
>> +otherwise be stored to can introduce undefined behavior.</p>
>
> Is it worth mentioning that this doesn't apply to pointers that
> don't escape to other threads?

Possibly; I started out trying to write a sentence like that, but it
wasn't clear. I'll think about it a bit more.

I'll try to address the other issues you mentioned as well.

-Eli