[X86] X86DAGToDAGISel::matchBitExtract(): extract 'lshr' from `X`
authorRoman Lebedev <lebedev.ri@gmail.com>
Fri, 16 Nov 2018 13:04:54 +0000 (13:04 +0000)
committerRoman Lebedev <lebedev.ri@gmail.com>
Fri, 16 Nov 2018 13:04:54 +0000 (13:04 +0000)
commit90c5b3f78ecfc08a428ea6022a5e80ddc437b99b
tree7befdbc238b05da6bc4739faf06ac89b05f67c86
parent831be096c72fc29d62f641f95d97a35f463eb202
[X86] X86DAGToDAGISel::matchBitExtract(): extract 'lshr' from `X`

Summary:
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.
We could just insert those 8 bits of shift amount into control,
but it is better to instead zero-extend them, and 'or' them in place.

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.

Reviewers: RKSimon, craig.topper, spatel, andreadb

Reviewed By: RKSimon, craig.topper, andreadb

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D54095

llvm-svn: 347048
llvm/lib/Target/X86/X86ISelDAGToDAG.cpp
llvm/test/CodeGen/X86/extract-bits.ll