[llvm-commits] [llvm] r145913 - /llvm/trunk/docs/LangRef.html
Dan Gohman
gohman at apple.com
Tue Dec 6 18:17:06 PST 2011
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
More information about the llvm-commits
mailing list