[llvm-dev] killing undef and spreading poison

Nuno Lopes via llvm-dev llvm-dev at lists.llvm.org
Thu Jun 15 07:31:25 PDT 2017


The GVN example we provided was supposed to be a sufficient argument.
But.. see section 3.2 of the paper you mentioned for another example  
of why a non-deterministic jump on poison/undef is not a good idea.
Alternatively see slide 12 of this:  
http://llvm.org/devmtg/2016-11/Slides/Lopes-LongLivePoison.pdf
And a miscompilation: https://bugs.llvm.org/show_bug.cgi?id=21412

See also my reply to your email yesterday. You cannot drop poison like  
you drop nsw; that doesn't exist (currently).

Nuno



Citando Peter Lawrence via llvm-dev <llvm-dev at lists.llvm.org>:

> Daniel,
>            Thanks for taking the time to respond.
>
> Regarding GVN and newGVN, I recently finished a search through the
> llvm-dev archives for “nsw” in the subject line, and GVN was discussed in
> some of those threads [1].
>
> In particular it was claimed that there was a right choice for GVN  
> to make given
> two ADD instructions, one with the “nsw” attribute and one without, the one
> without ‘nsw’ must be the representative.
>
> This was described as a correctness issue, not an optimality issue. IE if you
> are going to CSE those two ADDs, it is safe to loose information  
> (drop the ‘nsw’)
> but it is unsafe to put ‘nsw’ on to an operation that didn’t already have it
> because that is like inserting an “llvm.assume" where there was none.
>
> So I  am extrapolating from ’nsw’ instruction attribute, to ‘poison’  
> value attribute,
> And wondering if (expecting that) you think the same logic applies.
>
> I make no claim as to optimality, which seems to be what you are getting at.
>
> Are you saying the post I am citing is incorrect ?
> Or that I misunderstood it ?
> Or could it be that you misread my email ?
>
>
>
> Yes I am hoping *Nuno* can come up with a better example.  There is a claim
> that “branch on poison is undefined behavior” is the right  
> definition,  which is
> not justified in the Paper [2], which John is waffling on,  which no  
> one seems to
> be able to justify, and which gives the appearance at least of  
> flying in the face
> of common sense.
>
> This is the IR definition we’re talking about here, the literal  
> heart and soul of
> the compiler, everyone should be at least a little bit concerned.
>
>
> Peter Lawrence.
>
>
> [1.   I’m having difficulty locating the post, here’s one that is similar
>
> 	Tue Jul 22, 2014 “On semantics of add instruction - nsw, nuw”
>
>    It also occurs to me that the more detailed post I am remembering but
>    can’t find might have been about SCEV rather than GVN ]
>
>
> [2.  “Taming undefined behavior in LLVM” ]
>
>
>
>
>
>> On Jun 14, 2017, at 2:12 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
>>
>>
>>
>> On Wed, Jun 14, 2017 at 1:26 PM, Peter Lawrence via llvm-dev  
>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>
>> 1. —————
>> Dan,
>>        The reasoning given below for how GVN operates seems odd to me,
>>
>> Poison is an attribute of a value,  just like nsw is an attribute  
>> of an operation,
>>
>> So when GVN sees a pair of equal values, one of which has an extra  
>> attribute,
>> The proper choice for representative value is the one without the attribute,
>>
>> There are many many choices of what make *good* representative  
>> values in NewGVN.
>> I would deny any assertion that there is a proper choice, and that  
>> if there is one, it must be what you suggest :)
>> You actually can prove that there is no optimal such choice.   
>> Different choices will lead you to discover different congruences  
>> in any practical algorithms, even complete ones (as the issues here  
>> are orthogonal to herbrand equivalence., and instead related to  
>> inference of facts from control flow and other things, as well as  
>> what the results from symbolic evaluation and simplification)
>> There are examples in the paper cited by newgvn of situations where  
>> different choices of values for predicate and phi inference will  
>> enable you to discover different congruences.
>>
>> More importantly, given the other purpose of the representatives is  
>> to be used during simplification and symbolic evaluation, something  
>> we know we *cannot* possibly be optimal at, i do not believe you  
>> can assert that there is such an easily knowable best representative.
>>
>> There is also no representation we could pick that would avoid all  
>> issues for others
>>
>>
>>
>> Thoughts ?
>> Comments ?
>> Questions ?
>>
>> The middle one.
>>
>> I'm going to be frank and honest:
>> I don't feel like i have a good understanding of what your goal  
>> here is, or what you see your role as.
>> I can tell you, again, completely personally, that i find your  
>> approach off-putting at times.
>> To give a concrete example, here, what i see (again, from *my*  
>> perspective), is you are asserting things to me and asking me to  
>> confirm them or disprove them. I generally have not found this to  
>> be a good collaborative approach to increasing understanding.  You  
>> then say"If Dan agrees with the above then can we come up with a  
>> better example".  In practice, so far, that has meant "can *Nuno*  
>> come up with a better example" (IE the we seems to be turning into  
>> work for others).
>>
>> I do not say this as a true complaint so much as a explanation of  
>> why i don't feel like i understand your perspective on things, and  
>> i think it would be  helpful for me to be able to.
>> I also certainly do not claim that there are not multiple ways to  
>> approach problem solving, communities, etc, or that what I or  
>> anyone else does is best.



More information about the llvm-dev mailing list