This defines a 'fastcc' for the VE target and implements vreg-to-vreg copy for parameter passing. The 'fastcc' extends the standard CC for SX-Aurora with register passing of vector-typed parameters and return values.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
410 ms | linux > HWAddressSanitizer-x86_64.TestCases::sizes.cpp |
Event Timeline
It is better to make a different NFC patch for modifications on the mechanism to retrieve the calling convention. And need a regression test from caller side.
llvm/lib/Target/VE/VEISelLowering.cpp | ||
---|---|---|
43 | These modifications are independent from passing vector registers on registers patch. |
Thank you for adding caller side test. However, it is not possible to examine these tests whether fastcc is implemented correctly or not, unfortunately. How about upstream vector load and vector store first, then upstream this with caller side tests something like load and call, and return and store? After that, upstream vector copy with callee side tests.
Here is why the patches are structured this way relying on fastcc:
My actual goal is to put a patch on phabricator that demonstrates the hpce/develop isel mechanism for vector instructions. This should come with single vector instruction tests (one vector inst emitted per test function).
Using fastcc we can write single vector instruction tests that do not require any vld nor vst nor vor, if we order the vector operands in IR to match the vreg order of the CC.
However, to emit any valid vector instruction code in the first place, i need LVLGen upstream (D90850) and to upstream LVLGen we need a test for it. The VOR required for fastcc is such a test and it does not require any isel patterns.
This current patch (D90842) is just a stub for fastcc to make D90850 smaller.
fastcc does not support vargs. Citing the LLVM LangRef :
“fastcc” - The fast calling convention
[..]
This calling convention does not support varargs and requires the prototype of all callees to exactly match the prototype of the function definition.
I don't say varargs. I meant vector arguments. This patch define fastcc and declare how to pass vector arguments and vector return values using vector registers. Why don't you make tests to check function calls using vector registers correctly? Your tests don't show %v0 or %v1 in checking assembly code, so it is not possible to check the correctness, IMO.
I'll commit the CSR_preserve_all change standalone with D90912