[llvm] r283937 - GlobalISel: support selection of extend operations.

[Tim Northover via llvm-commits]

Hi Quentin,

On 11 Oct 2016, at 21:16, Quentin Colombet <qcolombet at apple.com> wrote:
> I was adding the support for copies and bit casts (we stepped a bit on each other toes, sorry about that x)) and that led me to refactor a bit the handling of G_ANYEXT. (r283972)

Oops.

> I wanted to point out that I was surprised that G_ANYEXT is handled differently than G_SEXT and G_ZEXT. I would have expected G_ANYEXT to be a shrunk version of the cheapest expansion of both for the related types.
> What do you think?

I'm not sure I understand this. For G_SEXT and G_ZEXT we have to specifically set some high bits of the register, but G_ANYEXT is mostly a typing convenience and we can leave the bits as they are (so either a COPY or a SUBREG_TO_REG).

> Although, I notice that we unconditionally generate BFM-like instructions for G_SEXT and G_ZEXT. That is correct but it seems sub-optimal to me.

The only time I think we could omit them would be a 32-bit -> 64-bit G_ZEXT where we know the input comes from a real 32-bit instruction (so no G_ADD(s64) -> G_TRUNC(s32) -> G_ZEXT(s64)). Extends from a <32-bit type probably have rubbish in the high bits that needs clearing, and nothing really produces sign bits in the high end.

Am I missing some wider class of cases where no actual modification is needed?

> Is the intent to use G_ANYEXT every time we know we don’t need to generate BFM or is this a limitation in the current handling?

Yes, G_ANYEXT produces a value of the destination type where the low bits come from the source register and bits above that are undef. At least that's what I view it as. If you use G_ZEXT or G_SEXT you're saying exactly what those bits should be, and the chances are that needs setting.

We may well end up with something like the DAG's AssertSExt and AssertZExt too for when we know via some other means (e.g. ABI constraint) that a value has been extended. I think that's mostly an optimization concern though, and probably only really relevant when we get to writing a combiner.

Cheers.

Tim.