[PATCH] D90176: [AArch64] Improve lowering of insert_vector_elt with 0.0 consts.

Eli Friedman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Oct 27 13:39:14 PDT 2020


efriedma added a comment.

In D90176#2357415 <https://reviews.llvm.org/D90176#2357415>, @fhahn wrote:

> In D90176#2357309 <https://reviews.llvm.org/D90176#2357309>, @efriedma wrote:
>
>> We could turn this into a more general combine,  We use fmov from a GPR to materialize fp constants in other cases.  But maybe just zero is fine to start.
>
> So for other FP constants that have values that can be cheaply matrialized into GPRs? That would be good. I guess that would be helpful in all contexts where we can use GPRs directly instead of FPRs. Is there a way to match something like that generically?

For values that aren't literals, there would be a bitcast or something like that.

For literals, the rule for whether we use a GPR is complicated; see AArch64TargetLowering::isFPImmLegal.  But once we get to isel, the actual lowering is pretty simple; see bitcast_fpimm_to_i32.

> Happy to look into that, but would prefer to start just with the 0.0 case.
>
>>> I am not sure if we can easily express this in the tablegen descriptions, because INS*vi*gpr is only defined for integer vectors and I am not sure how to convert things there.
>>
>> MachineInstrs don't distinguish between integer and float vectors; there's only V64/V128 register classes.  So the types only matter for the inputs to tablegen patterns, not the outputs.  You can write a pattern that takes a float vector as an input and produces an INSvi32gpr without any casting.
>
> Thanks! I think I was running into some ambiguity with the patterns, not sure exactly what was going on. Would you prefer the tablegen version?

I'm a little worried this version will make other combines more complicated; I'd prefer the TableGen version if it isn't too hard.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90176/new/

https://reviews.llvm.org/D90176



More information about the llvm-commits mailing list