[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