[llvm] r283937 - GlobalISel: support selection of extend operations.
Quentin Colombet via llvm-commits
llvm-commits at lists.llvm.org
Wed Oct 12 09:27:22 PDT 2016
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.
More information about the llvm-commits
mailing list