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

[Quentin Colombet via llvm-commits]

Hi Tim,

> On Oct 12, 2016, at 9:18 AM, Tim Northover <tnorthover at apple.com> wrote:
> 
> 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.

No worries, I just hope I didn’t break something else when I merged our changes (make check passed, we are good right? :P).
> 
>> 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?

No, that sounds accurate and the distinction between G_ANYEXT and the other makes sense to me (though I think it different from SDISel). I thought we could still just use a SUBREG_TO_REG for 32-bit to 64-bit when with zero extend.

> 
>> 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.

Thanks for the confirmation.
> 
> 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.

Agreed.

Thanks,
-Quentin

> 
> Cheers.
> 
> Tim.