[PATCH] D154078: [X86] Don't elide argument copies for scalarized vectors (PR63475)

[Nikita Popov via Phabricator via llvm-commits]

nikic added a comment.

In D154078#4476524 <https://reviews.llvm.org/D154078#4476524>, @pengfei wrote:

> Why do we change the distance from 4 to 8 in callee rather than change 8 to 4 for caller?
> Although we don't have a standard calling converion for illegal types in IR, and what makes it more corner is its power-of-2 vector <8 x i32> is illegal too (https://godbolt.org/z/ds9WGPTeP), I think we still should make it close to practical converion, i.e., https://godbolt.org/z/YoMbzxzr8

My understanding of how this works is that we legalize the vector into (legally typed) parts, and then those parts get assigned to registers until we run out of argument registers. At that point the remainder is passed on the stack. How that looks like is determined by the calling convention -- on x86_64 it means that the 32-bit registers get pushed into 64-bit stack slots.

I don't think we can make the 32-bit registers spill into 32-bit stack slots for the specific case that they come from an illegal vector -- and it wouldn't make a lot of sense, if you consider that only parts of the vector might get passed via stack, and the rest via registers, so you wouldn't get a complete vector on the stack anyway.

The other thing we can do is to chose a better argument passing legalization for the vector, and e.g. pass it via combination of widening and splitting as two `<4 x i32>` vectors instead. This would of course be the more efficient calling convention.

The problem here is that SDAG argument lowering currently doesn't support this. It supports widening a vector and it supports splitting a vector, but it doesn't support doing both. I took a look, and supporting this doesn't look particularly easy.

In any case, I still think that the fix here makes sense, in that //if// a vector gets scalarized, we should disable the argument copy elision optimization. The question whether the vector gets scalarized or not is ultimately a separate one...


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

https://reviews.llvm.org/D154078