This is an archive of the discontinued LLVM Phabricator instance.

Add FMF to hasPoisonGeneratingFlags/dropPoisonGeneratingFlags
ClosedPublic

Authored by reames on Dec 9 2021, 11:48 AM.

Details

Summary

These flags are documented as generating poison values for particular input values. As such, we should really be consistent about their handling with how we handle nsw/nuw/exact/inbounds.

In terms of the test changes, a couple notes:

  • I did a bunch of cleanup in previous change series to reduce the test diff. Make sure you apply to ToT if applying locally.
  • The freeze changes are correct, and desired.
  • The shuffle changes look to be over conservative to me, but glancing at the history, it appears that's a complicated area. I think we should take the potential regression in quality here to have the consistency, and revisit the basic question of where we need to drop flags separately.

Diff Detail

Unit TestsFailed

Event Timeline

reames created this revision.Dec 9 2021, 11:48 AM
reames requested review of this revision.Dec 9 2021, 11:48 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 9 2021, 11:48 AM
nikic added a comment.Dec 13 2021, 7:18 AM

Can you please rebase now that D115526 has landed?

reames updated this revision to Diff 393922.Dec 13 2021, 9:22 AM

Rebase as requested.

spatel added inline comments.Dec 13 2021, 11:40 AM
llvm/test/Transforms/InstCombine/shuffle_select-inseltpoison.ll
779

I looked at the code for this and related transforms in "foldSelectShuffle", and it's a mess.
We have lots of miscompiles like this:
https://alive2.llvm.org/ce/z/MHoacO
...and I don't think proposed but uncommitted patches like D93818 / D103874 resolve those.

We probably need to add an identity shuffle with undef/poison elements preserved from the original code. Otherwise, we are potentially leaking poison from the variable value in the original code. This could take a few patches to fix, so I wouldn't hold this patch up for it (but I'll try to get that sorted out soon).

llvm/test/Transforms/PhaseOrdering/ARM/mve-floatreduce.ll
16 ↗(On Diff #393922)

This diff should have disappeared with the rebase?

reames added inline comments.Dec 13 2021, 12:48 PM
llvm/test/Transforms/InstCombine/shuffle_select-inseltpoison.ll
779

I don't follow this comment at all, so if there's anything in here you want me to change, please rephrase.

llvm/test/Transforms/PhaseOrdering/ARM/mve-floatreduce.ll
16 ↗(On Diff #393922)

This passed check-llvm after the rebase, and the CI build checks agree, so no.

spatel added inline comments.Dec 13 2021, 1:35 PM
llvm/test/Transforms/InstCombine/shuffle_select-inseltpoison.ll
779

Sorry, that was confusing. There are problems with this set of transforms that are independent of this patch. The test changes here are minor, so I am not worried about them. Nothing for you to do in this patch.

llvm/test/Transforms/PhaseOrdering/ARM/mve-floatreduce.ll
16 ↗(On Diff #393922)

Hmm...if I apply this patch locally, this test fails for me...

; CHECK-NEXT: [[TMP5:%.*]] = fadd reassoc nsz arcp contract afn <8 x half> [[TMP1]], [[TMP4]]
              ^
<stdin>:13:41: note: scanning from here
 %4 = bitcast <4 x i32> %3 to <8 x half>
                                        ^
<stdin>:13:41: note: with "TMP1" equal to "%1"
 %4 = bitcast <4 x i32> %3 to <8 x half>
                                        ^
<stdin>:13:41: note: with "TMP4" equal to "%4"
 %4 = bitcast <4 x i32> %3 to <8 x half>
                                        ^
<stdin>:14:2: note: possible intended match here
 %5 = fadd fast <8 x half> %1, %4
 ^

Input file: <stdin>
Check file: /Users/spatel/GitHub/llvm-project/llvm/test/Transforms/PhaseOrdering/ARM/mve-floatreduce.ll

-dump-input=help explains the following input dump.

Input was:
<<<<<<
           .
           .
           .
           8: entry: 
           9:  %0 = shufflevector <8 x half> %in, <8 x half> poison, <8 x i32> <i32 1, i32 0, i32 3, i32 2, i32 5, i32 4, i32 7, i32 6> 
          10:  %1 = fadd fast <8 x half> %0, %in 
          11:  %2 = bitcast <8 x half> %1 to <4 x i32> 
          12:  %3 = shufflevector <4 x i32> %2, <4 x i32> poison, <4 x i32> <i32 1, i32 undef, i32 3, i32 undef> 
          13:  %4 = bitcast <4 x i32> %3 to <8 x half> 
next:16'0                                             X error: no match found
next:16'1                                               with "TMP1" equal to "%1"
next:16'2                                               with "TMP4" equal to "%4"
          14:  %5 = fadd fast <8 x half> %1, %4
spatel added inline comments.Dec 13 2021, 1:40 PM
llvm/test/Transforms/PhaseOrdering/ARM/mve-floatreduce.ll
16 ↗(On Diff #393922)
reames updated this revision to Diff 394091.Dec 13 2021, 5:11 PM

2nd try at a rebase

This *definitely* passes check-llvm.

reames added inline comments.Dec 13 2021, 5:12 PM
llvm/test/Transforms/PhaseOrdering/ARM/mve-floatreduce.ll
16 ↗(On Diff #393922)

Did a second rebase cycle, and the diff appears to have disappeared. Clearly must have done some wrong the first time, not really sure what though.

spatel accepted this revision.Dec 14 2021, 5:13 AM

LGTM - as I mentioned in an inline comment, the remaining regressions seem minor, and I will try to fix them in follow-up patches.

This revision is now accepted and ready to land.Dec 14 2021, 5:13 AM
nikic accepted this revision.Dec 14 2021, 5:17 AM

LG as well, thanks for following up on this.

This revision was landed with ongoing or failed builds.Dec 14 2021, 8:43 AM
This revision was automatically updated to reflect the committed changes.