This is an archive of the discontinued LLVM Phabricator instance.

[instcombine] Do demanded elts last when visiting extractelement
ClosedPublic

Authored by reames on Dec 8 2021, 1:33 PM.

Details

Summary

This reorders existing transforms to put demanded elements last. The reasoning here is that when we have an example which can be scalarized or handled via demanded bits, we should prefer scalarization as that doesn't require dropping flags on arithmetic instructions.

This doesn't show major changes in the tests today, but once I add support for fast math flags to dropPoisonGeneratingFlags this becomes glaringly obvious.

Diff Detail

Event Timeline

reames created this revision.Dec 8 2021, 1:33 PM
reames requested review of this revision.Dec 8 2021, 1:33 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 8 2021, 1:33 PM
reames added inline comments.Dec 8 2021, 1:34 PM
llvm/test/Transforms/InstCombine/X86/x86-avx512-inseltpoison.ll
1066–1067

The index types here differ because we don't canonicalize either way, and depending on transform order we can get either. D115387 adds the canonicalization, but I'd prefer not to block this patch on that one.

nikic accepted this revision.Dec 9 2021, 12:07 AM

LGTM, makes sense to me.

llvm/test/Transforms/InstCombine/scalarization.ll
223–224

Update comment

This revision is now accepted and ready to land.Dec 9 2021, 12:07 AM
spatel accepted this revision.Dec 9 2021, 6:29 AM

LGTM

Side note on poison with FMF: this came up recently in D112117, and I'm not sure yet how to solve it. I think the issue is that "reassoc" effectively implies "nnan" + "ninf" + "nsz". Ie, if we are allowed to reorder FP math, anything is possible, and we can't be blamed for creating any of the special FP values...otherwise, we can't safely reorder any FP math.

Side note on poison with FMF: this came up recently in D112117, and I'm not sure yet how to solve it. I think the issue is that "reassoc" effectively implies "nnan" + "ninf" + "nsz". Ie, if we are allowed to reorder FP math, anything is possible, and we can't be blamed for creating any of the special FP values...otherwise, we can't safely reorder any FP math.

Well, at the moment, I'm mostly focused on simple consistency on how we handle explicit nnan and ninf flags. We drop fmf flags (specifically no-nans and no-infs) in some cases, but not others. At least one case we don't drop appears to be a semantic bug per the current LangRef wording.

I haven't gotten to looking at the reduction changes to see if those are spurious. The first version of the patch I wrote changed a ton of tests, mostly undesirably. I'm currently picking a test, figuring out what's going on, fixing that issue, then iterating. I'll let you know once I get to the reduction question.

Note that the "does reassoc imply nnan and ninf" is basically a different question. All that means is that we need to treat reasoc as poison generating. The current LangRef does not say that, so it be both a LangRef and implementation change.

This revision was landed with ongoing or failed builds.Dec 9 2021, 10:05 AM
This revision was automatically updated to reflect the committed changes.