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

[Dan Gohman]

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.

Dan