[llvm] [SystemZ] Handle IR struct arguments correctly. (PR #169583)

[Jonas Paulsson via llvm-commits]

JonPsson1 wrote:

- The broken (previous) test case fixed in CanLowerReturn by recognizing not only i128 arguments, but any >64 bit int argument.

- Tests improved / reworked to cover hopefully all twists including incoming args, passing arg to call, saving/loading from memory and returning. Not sure if this is a little too much?

- See inline question about the variation as to where an i72 resides in memory in its 16 byte slot.

ComputeValueVTs() is called in visitRet(), and it computes the offsets for each (flattened) argument, but when creating the store, it simply adds that offset, which means that the i72 is stored at 'Offs' instead of 'Offs + (16 - 9)', which would make more sense with an implicit extension to i128. It seems that generally i72 are handled in memory with 16 bytes, so maybe this is an endian problem? It would make more sense to have the LSB stored in the same place regardless if it's an i72 or i128, and it could be done with a single VST. OTH, not sure if this matters as this is non-ABI and it "works", and it is likely rare..?

> Is there any particular reason for using fastcc everywhere? This should work with the default calling convention just the same, shouldn't it?

I added it because the default "ccc" (per lang.ref) "matches the target C calling conventions", while fastcc "allows the target to use whatever tricks it wants to produce fast code for the target, without having to conform to an externally specified ABI". It's not needed for the tests, so I removed it. Maybe this then is considered the default "behavior" when the actual SystemZ ABI is broken, but with the "bug" being in the FE(?).



https://github.com/llvm/llvm-project/pull/169583