<div dir="ltr"><div><div>This may not apply at all here as I really don't understand the intricacies of undef/poison (and especially "freeze") - I'm just following the discussion trying to understand what the argument is.<br></div>So what I mean is that with floating point values, code within an `if (a == a)` condition is obviously not guaranteed to execute. Of course, you guys aren't discussing floating point here - you're discussing integers. But it seems to me like this type of optimization seems to treat an integer "undef" similarly to a floating point NaN. With my very limited understanding of the problem at hand, this seems like a logical thing.<br><br></div>I apologize if this is a naive view or if it distracts from the discussion.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 19, 2017 at 7:02 PM, Peter Lawrence via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sanjoy,<br>
The point is this, you have to take a stand one way or<br>
the other on the function-inlining issue:<br>
<br>
<br>
[1. this function *always* executes statement S,<br>
F(a) {<br>
If (a == a) S;<br>
}<br>
but in llvm if you inline it and “a” happens to be “undef” then nothing can<br>
be said about whether statement S is executed. This is indefensible.]<br>
<br>
<br>
My belief is this: that llvm exists for a utilitarian purpose,<br>
and that llvm currently violates that utilitarian goal by violating<br>
the users expectations in the function-inlining example.<br>
<br>
<br>
So the question is, where do you stand ?<br>
<br>
<br>
Peter Lawrence.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
> On Jun 19, 2017, at 9:35 AM, Sanjoy Das <<a href="mailto:sanjoy@playingwithpointers.com">sanjoy@playingwithpointers.<wbr>com</a>> wrote:<br>
><br>
> Hi Peter,<br>
><br>
> On Mon, Jun 19, 2017 at 8:36 AM, Peter Lawrence<br>
> <<a href="mailto:peterl95124@sbcglobal.net">peterl95124@sbcglobal.net</a>> wrote:<br>
>> You’ve hit the nail on the head !, but I don’t think we’ve correctly<br>
>> identified the root cause of the problem yet.<br>
>><br>
>> Rather the problem is with how we incorrectly cse and copy-propagate it:<br>
>> x = undef<br>
>> if (x == x)<br>
>> —————> this is an illegal copy-propagation —————><br>
>> if (undef == undef)<br>
>><br>
>> If you don’t believe this is illegal then we end up with the absurdity of the<br>
>> function-inlining example [1], and the argument against the function-inlining<br>
><br>
> I don't think [1] is absurd. LLVM IR is not a programming language,<br>
> and it is okay for it to have semantics that would seem odd in a<br>
> programming language.<br>
><br>
>> example is so compelling that John decided to drop out of the argument,<br>
>> IE he gave up because it is indefensible.<br>
><br>
> I think he "gave up" because he has better things to do than argue with you. :)<br>
><br>
>> Apparently this copy-propagation has been justified by thinking of "undef"<br>
>> as an IR "constant” and that any optimization you can do to a “constant”<br>
>> can also be done to “undef” without further thought.<br>
>><br>
>> Instead each ‘undef’ should be thought of as a live on entry register, IE an<br>
><br>
> Since you're talking about "each" undef, I presume you want to have an<br>
> undef instruction? As I've said before, this would be equivalent to<br>
> "freeze(poison)" in the new semantics. It does not address the<br>
> problem of optimizing things like `a s< (a +nsw 1)` (so you'll need a<br>
> poison-like thing for that anyway).<br>
><br>
>> incoming argument physical register, and “x = undef” cannot be optimized<br>
>> any more than “x = PhysReg0”, in particular multiple uses of X does not mean<br>
>> multiple incoming argument registers, and separate instances of “undef”<br>
>> cannot be equated any more than distinct incoming argument registers.<br>
>><br>
>> To the argument that this may create unnecessary register pressure I say<br>
>> that is a register allocator issue not an IR issue, the register allocator can<br>
>> and should figure this out and do the right thing.<br>
><br>
> Sure, that's a consistent proposal. However, practically, the onus is<br>
> on you to prove this is reasonable from a performance standpoint.<br>
><br>
> -- Sanjoy<br>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>