You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The difference in instcombine is in InstCombinerImpl::SimplifyUsingDistributiveLaws() -> getBinOpsForFactorization().
We recognize add-of-shifts as a factorized multiply, but not or-of-shifts.
We're arguing for "mul" in this example, and we already do that partially, so the backend should be equipped to decompose back to shift+logic.
Interestingly, the -reassociate pass already has a reverse transform from -instcombine that turns the 'or' into 'add': "ShouldConvertOrWithNoCommonBitsToAdd"
If we allow shift opcodes there, that's probably the quickest fix.
So it seems fine to add 'shl' to the opcode list. It's awkward that we have opposing canonicalizations in different passes, but I don't have any better ideas.
I'll add a reassociate test and a phase ordering test to prevent this from regressing.
Extended Description
https://simd.godbolt.org/z/E15MrP
This successfully combines to a zext+mul+add (I think technically it could be zext+mul+or)?
But this:
completely fails and we end up with a long shift+or chain.
The text was updated successfully, but these errors were encountered: