[llvm] 64af9f6 - [InstSimplify] add 'x + poison -> poison' (needed for NewGVN)
Philip Reames via llvm-commits
llvm-commits at lists.llvm.org
Sun Jan 2 10:09:58 PST 2022
On 1/2/22 9:49 AM, Nuno Lopes wrote:
> That's a long story..
>
> The return value of InstSimplify is only guaranteed to be a
> *refinement* of the input, meaning it's not necessarily equivalent.
> This is perfectly fine. LLVM can transform undef -> 0; it removes
> behavior.
>
> GVN algorithms, on the other hand, compute classes of equivalent
> expressions. But NewGVN uses InstSimplify to canonicalize expressions
> before computing the equivalence classes. But, ouch, there's a
> mismatch: GVN deals with equivalences, while InstSimplify gives it
> refinements.
>
> A workaround implemented at the time was to disable some refinements
> from InstSimplify by disabling the matching of undef. This is not a
> complete solution, but a band aid (in theory, at least, I didn't fuzz
> it to check if it's possible to get a miscompilation in practice).
> See https://llvm.org/doxygen/structllvm_1_1SimplifyQuery.html
Ah, gotcha. The refinement vs equivalence point makes sense.
A couple of suggestions/ideas:
* The naming in the code should match the refinement terminology.
AllowRefinement would be a much clearer name than WithoutUndef. In
particular, the "isUndefValue" in the code is confusing.
* We really need a way to test the logic and fuzz it. As a
suggestion, maybe add an off-by-default option to the instsimplify
pass called "-instsimplify-disallow-refinement", and write LIT cases
for the interesting differences?
* Once we had that, using alive2 to check fuzz outputs for unexpected
refinements would be pretty straight forward.
>
> Note that InstSimplify does have transformations that are wrong in the
> presence of undef. It applies redistributivity freely, which is not
> guaranteed to yield a correct result until we kill undef. But again,
> it disables undef matching when it recurses, so maybe it's ok in
> practice too (candidate for fuzzing too).
And a great case to cover with some LIT tests. :)
>
> Nuno
>
>
> -----Original Message----- From: Philip Reames
> Sent: Sunday, January 2, 2022 5:28 PM
> Subject: Re: [llvm] 64af9f6 - [InstSimplify] add 'x + poison ->
> poison' (needed for NewGVN)
>
> Er, that really stinks that the public API of this utility is broken
> then.
>
> Can you explain the context of why newgvn needs to "disable matching on
> undef" and instsimplify is fine to run without doing so? If there's a
> clear comment in the code already, a pointer to that is fine.
>
> Philip
>
> On 1/2/22 9:26 AM, Nuno Lopes wrote:
>> I don't think it can be reproduced with InstSimplify alone.
>> InstSimplify already simplified the test case I added. NewGVN
>> disables matching of undef, which InstSimplify does not.
>>
>> Nuno
>>
>>
>> -----Original Message-----
>> From: Philip Reames
>> Sent: Sunday, January 2, 2022 5:10 PM
>> Subject: Re: [llvm] 64af9f6 - [InstSimplify] add 'x + poison ->
>> poison' (needed for NewGVN)
>>
>> I agree, this really needs a test. I see you later added a GVN test for
>> the same, can you add an instsimplify one please?
>>
>> Philip
>>
>> On 12/30/21 4:02 AM, Roman Lebedev via llvm-commits wrote:
>>> Test?
>>>
>>> On Thu, Dec 30, 2021 at 2:53 PM Nuno Lopes via llvm-commits
>>> <llvm-commits at lists.llvm.org> wrote:
>>>>
>>>> Author: Nuno Lopes
>>>> Date: 2021-12-30T11:52:42Z
>>>> New Revision: 64af9f61c30191482979c6883e4cc63703f12010
>>>>
>>>> URL:
>>>> https://github.com/llvm/llvm-project/commit/64af9f61c30191482979c6883e4cc63703f12010
>>>> DIFF:
>>>> https://github.com/llvm/llvm-project/commit/64af9f61c30191482979c6883e4cc63703f12010.diff
>>>>
>>>> LOG: [InstSimplify] add 'x + poison -> poison' (needed for NewGVN)
>>>>
>>>> Added:
>>>>
>>>>
>>>> Modified:
>>>> llvm/lib/Analysis/InstructionSimplify.cpp
>>>>
>>>> Removed:
>>>>
>>>>
>>>>
>>>> ################################################################################
>>>>
>>>> diff --git a/llvm/lib/Analysis/InstructionSimplify.cpp
>>>> b/llvm/lib/Analysis/InstructionSimplify.cpp
>>>> index 1c26ab3619089..4a8dc754349bd 100644
>>>> --- a/llvm/lib/Analysis/InstructionSimplify.cpp
>>>> +++ b/llvm/lib/Analysis/InstructionSimplify.cpp
>>>> @@ -620,6 +620,10 @@ static Value *SimplifyAddInst(Value *Op0,
>>>> Value *Op1, bool IsNSW, bool IsNUW,
>>>> if (Constant *C = foldOrCommuteConstant(Instruction::Add, Op0,
>>>> Op1, Q))
>>>> return C;
>>>>
>>>> + // X + poison -> poison
>>>> + if (isa<PoisonValue>(Op1))
>>>> + return Op1;
>>>> +
>>>> // X + undef -> undef
>>>> if (Q.isUndefValue(Op1))
>>>> return Op1;
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> llvm-commits mailing list
>>>> llvm-commits at lists.llvm.org
>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20220102/1362ad18/attachment-0001.html>
More information about the llvm-commits
mailing list