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

[Eli Friedman]

On Tue, Dec 6, 2011 at 6:17 PM, Dan Gohman <gohman at apple.com> wrote:
> On Dec 5, 2011, at 8:21 PM, Eli Friedman wrote:
>
>> On Mon, Dec 5, 2011 at 7:35 PM, Dan Gohman <gohman at apple.com> wrote:
>>> Author: djg
>>> Date: Mon Dec  5 21:35:58 2011
>>> New Revision: 145913
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=145913&view=rev
>>> Log:
>>> Fix a subtle semantic issue with poison values that came up in
>>> recent discussions. Poison can't make every value that depends on
>>> it act in maximally undefined ways, because the optimizer may still
>>> hoist code following the usual rules for undef. Make Poison invoke
>>> its full undefined behavior only when it reaches an instruction with
>>> externally visible side effects.
>>>
>>> Modified:
>>>    llvm/trunk/docs/LangRef.html
>>>
>>> Modified: llvm/trunk/docs/LangRef.html
>>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/LangRef.html?rev=145913&r1=145912&r2=145913&view=diff
>>> ==============================================================================
>>> --- llvm/trunk/docs/LangRef.html (original)
>>> +++ llvm/trunk/docs/LangRef.html Mon Dec  5 21:35:58 2011
>>> @@ -2512,10 +2512,9 @@
>>>  <div>
>>>
>>>  <p>Poison values are similar to <a href="#undefvalues">undef values</a>, however
>>> -   instead of representing an unspecified bit pattern, they represent the
>>> -   fact that an instruction or constant expression which cannot evoke side
>>> -   effects has nevertheless detected a condition which results in undefined
>>> -   behavior.</p>
>>> +   they also represent the fact that an instruction or constant expression which
>>> +   cannot evoke side effects has nevertheless detected a condition which results
>>> +   in undefined behavior.</p>
>>>
>>>  <p>There is currently no way of representing a poison value in the IR; they
>>>    only exist when produced by operations such as
>>> @@ -2572,22 +2571,21 @@
>>>
>>>  </ul>
>>>
>>> -<p>Whenever a poison value is generated, all values which depend on it evaluate
>>> -   to poison. If they have side effects, they evoke their side effects as if each
>>> -   operand with a poison value were undef. If they have externally-visible side
>>> -   effects, the behavior is undefined.</p>
>>> +<p>Poison Values have the same behavior as <a href="#undefvalues">undef values</a>,
>>> +   with the additional affect that any instruction which has a <i>dependence</i>
>>> +   on a poison value has undefined behavior.</p>
>>>
>>>  <p>Here are some examples:</p>
>>>
>>>  <pre class="doc_code">
>>>  entry:
>>>   %poison = sub nuw i32 0, 1           ; Results in a poison value.
>>> -  %still_poison = and i32 %poison, 0   ; Whereas (and i32 undef, 0) would return 0.
>>> +  %still_poison = and i32 %poison, 0   ; 0, but also poison.
>>>   %poison_yet_again = getelementptr i32* @h, i32 %still_poison
>>> -  store i32 0, i32* %poison_yet_again  ; undefined behavior
>>> +  store i32 0, i32* %poison_yet_again  ; memory at @h[0] is poisoned
>>
>> This change can't be right... storing to a poisoned address has to be
>> undefined behavior in any sane model.
>
>
> It's intentional. %still_poison is the result of anding with 0,
> so it has to behave as if it were all zeros, for SimplifyDemandedBits
> reasons.

Okay... I'm not sure the model is quite right, but that's correct in your model.

-Eli