This is an archive of the discontinued LLVM Phabricator instance.

[X86][BMI1]: X86DAGToDAGISel: select BEXTR from x & ~(-1 << nbits) pattern
ClosedPublic

Authored by lebedev.ri on Sep 20 2018, 7:34 AM.

Details

Summary

As discussed in D48491, we can't really do this in the TableGen, since we need to produce *two* instructions.
This only implements one single pattern. The other 3 patterns will be in follow-ups.
I'm not sure yet if we want to also fuse shift into here (i.e (x >> start) & ...)

Diff Detail

Repository
rL LLVM

Event Timeline

TBM BEXTRI is of no interest to us here.

lebedev.ri added inline comments.Sep 20 2018, 7:58 AM
lib/Target/X86/X86ISelDAGToDAG.cpp
2664–2671

Do we get rid of at least one extra instruction, or of both of them?

Use ISD::ANY_EXTEND. This gets rid of the extra movzbl of the NBits.
At least that is what D48768 already produced.
If NBits is larger than 64 (in 64-bit case), the shift was already undefined, i think?

And get rid of a last few unneeded movzbl.

I'm gonna stop here, i think this is the state for the review.

Fix stupid typo in comments - '8-bit low subreg' is AL, not AX.

craig.topper added inline comments.Sep 21 2018, 10:07 PM
lib/Target/X86/X86ISelDAGToDAG.cpp
2696

This can just be NBits.getSimpleValueType(). Using the -> is taking you to SDNode, but you already had SDValue. But can NBits ever not be i8? It came from a shift didn't it?

2704

I think I'd prefer to avoid using AL/AH here. It makes it seem like the instruction uses those registers and would be restricted to A/B/C/D registers.

lebedev.ri marked 2 inline comments as done.

Don't truncate NBits (it came from shift, therefore it's i8 already),
adjust comments.

lib/Target/X86/X86ISelDAGToDAG.cpp
2696

In *these* two patterns - yes, it came from shift.
But in the patterns c, d - it will not.
This was kind-of future-proofing, let's drop it.

(I feel like pointing out that this patch is largely free of all that BEXTRI drama, since the mask is not a constant.)

craig.topper added inline comments.Oct 1 2018, 10:33 AM
lib/Target/X86/X86ISelDAGToDAG.cpp
2697

Shouldn't we be using TargetOpcode::IMPLICIT_DEF not Undef?

lebedev.ri added inline comments.Oct 1 2018, 10:38 AM
lib/Target/X86/X86ISelDAGToDAG.cpp
2697

Hm, i thought i tried that initially.
But this current version is the only one that did not contain unneeded extra moves.
I will double-check.

Shouldn't this wait until we've moved BEXTR creation in D52426?

Shouldn't this wait until we've moved BEXTR creation in D52426?

I don't see why?
This only operates on non-constants, that only operates on constants.
There might be some rebasing pain, but it is my problem.

lebedev.ri marked 2 inline comments as done.
  • Use TargetOpcode::IMPLICIT_DEF.
This revision is now accepted and ready to land.Oct 10 2018, 11:39 PM
craig.topper added inline comments.Oct 10 2018, 11:45 PM
lib/Target/X86/X86ISelDAGToDAG.cpp
2671

ISD::isAllOnesConstant

LGTM

Thank you for the review!

We will now have a duplicating matchers in the tablegen, and here, for these patterns.
What do you think about also matching the BZHI here, and dropping the tablegen side?
Else, there will be no test coverage for the x & (-1 >> (bitwidth - c)) pattern, because it will be unfolded already.

lebedev.ri marked an inline comment as done.

Rebased.

This revision was automatically updated to reflect the committed changes.