This is an archive of the discontinued LLVM Phabricator instance.

[GlobalISel] Add a combine for ashr(shl x, c), c --> sext_inreg x, c'
ClosedPublic

Authored by aemerson on Aug 14 2020, 3:24 AM.

Details

Summary

By detecting this sign extend pattern early, we can uncover opportunities for more optimizations.

Diff Detail

Event Timeline

aemerson created this revision.Aug 14 2020, 3:24 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 14 2020, 3:24 AM
aemerson requested review of this revision.Aug 14 2020, 3:24 AM

Seems like it's missing a legality check, although I'm unclear on what the overall strategy for those is supposed to be

llvm/lib/CodeGen/GlobalISel/CombinerHelper.cpp
1895

Add a fixme for splat vectors?

llvm/test/CodeGen/AArch64/GlobalISel/prelegalizercombiner-ashr-shl-to-sext-inreg.mir
63

Could use some vector tests. I don't think m_ICst is smart enough to match splat vectors though. Adding the tests won't hurt for when that's solved.

Seems like it's missing a legality check, although I'm unclear on what the overall strategy for those is supposed to be

This is intended to run prelegalizer so I don't think we need it.

Seems like it's missing a legality check, although I'm unclear on what the overall strategy for those is supposed to be

This is intended to run prelegalizer so I don't think we need it.

Combines should probably try to support both. There's fragments of half implemented support for this

aemerson updated this revision to Diff 285675.Aug 14 2020, 9:45 AM

Seems like it's missing a legality check, although I'm unclear on what the overall strategy for those is supposed to be

This is intended to run prelegalizer so I don't think we need it.

Combines should probably try to support both. There's fragments of half implemented support for this

Every combine should check legality for each instruction it wants to generate? That seems like way overkill to me. The majority of the combines we do will be pre-legalize with post being used to clean up legalizer related things or do some lowering for isel. I think it should be done on as needed basis by whichever target needs a specific combine to be done post-legalize. Unless we have a better mechanism to do this that doesn't involve manually calling into LI every time,

Seems like it's missing a legality check, although I'm unclear on what the overall strategy for those is supposed to be

This is intended to run prelegalizer so I don't think we need it.

Combines should probably try to support both. There's fragments of half implemented support for this

Every combine should check legality for each instruction it wants to generate? That seems like way overkill to me. The majority of the combines we do will be pre-legalize with post being used to clean up legalizer related things or do some lowering for isel. I think it should be done on as needed basis by whichever target needs a specific combine to be done post-legalize. Unless we have a better mechanism to do this that doesn't involve manually calling into LI every time,

Currently we have CombinerHelper::isLegalOrBeforeLegalizer, which some combines use. CombinerInfo has IllegalOpsAllowed and LegalizeIllegalOps (which has the comment // TODO: Make use of this.) I guess the intent was these could re-legalize as it goes, and some reasonable subset of legality checks could be use for a profitability heuristic?

I think the majority of interesting combines are post-legalize, particularly when it comes to bit operations. Before legalization the MIR isn't particularly different than the source optimized IR, and the legalizer introduces new patterns.

Seems like it's missing a legality check, although I'm unclear on what the overall strategy for those is supposed to be

This is intended to run prelegalizer so I don't think we need it.

Combines should probably try to support both. There's fragments of half implemented support for this

Every combine should check legality for each instruction it wants to generate? That seems like way overkill to me. The majority of the combines we do will be pre-legalize with post being used to clean up legalizer related things or do some lowering for isel. I think it should be done on as needed basis by whichever target needs a specific combine to be done post-legalize. Unless we have a better mechanism to do this that doesn't involve manually calling into LI every time,

Currently we have CombinerHelper::isLegalOrBeforeLegalizer, which some combines use. CombinerInfo has IllegalOpsAllowed and LegalizeIllegalOps (which has the comment // TODO: Make use of this.) I guess the intent was these could re-legalize as it goes, and some reasonable subset of legality checks could be use for a profitability heuristic?

I think the majority of interesting combines are post-legalize, particularly when it comes to bit operations. Before legalization the MIR isn't particularly different than the source optimized IR, and the legalizer introduces new patterns.

I think those flags were intended for the full-fledged tablegen pattern combiner to use, but your point still stands. I'll add a legality check here but it seems like we need some more infrastructure to make use of IllegalOpsAllowed on the patterns in a more concise way.

aemerson updated this revision to Diff 286175.Aug 17 2020, 4:53 PM

Use isLegalOrBeforeLegalizer() and make the combine run unconditionally as part of the "all" set. This causes codegen changes in AMDGPU.

arsenm accepted this revision.Aug 18 2020, 6:36 AM
This revision is now accepted and ready to land.Aug 18 2020, 6:36 AM
This revision was landed with ongoing or failed builds.Aug 18 2020, 10:42 AM
This revision was automatically updated to reflect the committed changes.