[PATCH] D54095: [X86] X86DAGToDAGISel::matchBitExtract(): extract 'lshr' from `X`

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri created this revision.
lebedev.ri added reviewers: RKSimon, craig.topper, spatel.

As discussed in previous review, and noted in the FIXME, if `X` is actually an `lshr Y, Z` (logical!),
we can fold the `Z` into 'control`, and let the `BEXTR` do this too.
I *think* `INSERT_SUBREG SUB_8BIT` is the correct (or identical) choice here, not `zext`+`or`, https://godbolt.org/z/VdV5E9

We can only do this for `lshr`, not `ashr`, because we do not know that the mask cover only the bits of `Y`,
and not any of the sign-extended bits.

The obvious question is, is this actually legal to do?
I believe it is. Relevant quotes, from `Intel® 64 and IA-32 Architectures Software Developer’s Manual`, `BEXTR — Bit Field Extract`:

- `Bit 7:0 of the second source operand specifies the starting bit position of bit extraction.`
- `A START value exceeding the operand size will not extract any bits from the second source operand.`
- `Only bit positions up to (OperandSize -1) of the first source operand are extracted.`
- `All higher order bits in the destination operand (starting at bit position LENGTH) are zeroed.`
- `The destination register is cleared if no bits are extracted.`

FIXME: if we can do this, i wonder if we should prefer `BEXTR` over `BZHI` in such cases.


Repository:
  rL LLVM

https://reviews.llvm.org/D54095

Files:
  lib/Target/X86/X86ISelDAGToDAG.cpp
  test/CodeGen/X86/extract-bits.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D54095.172553.patch
Type: text/x-patch
Size: 29324 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20181105/8b608c3c/attachment.bin>