This adds vector splitting for vaarg instructions during type legalization
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
llvm/test/CodeGen/X86/legalize-vaarg.ll | ||
---|---|---|
1 ↗ | (On Diff #200470) | Please regenerate this with update_llc_test_checks.py |
llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp | ||
---|---|---|
1860 ↗ | (On Diff #200470) | This probably doesn't match how the vector will actually be passed on a big-endian target. Endianness doesn't affect the ordering of the elements of a vector in LLVM. (See also http://llvm.org/docs/BigEndianNEON.html .) |
llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp | ||
---|---|---|
1860 ↗ | (On Diff #200470) | Ok, so from what I understand then it should be fine to just remove this swap? |
llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp | ||
---|---|---|
1860 ↗ | (On Diff #200470) | Yes, but we need test coverage - copying legalize-vaarg.ll as a powerpc test with le and be targets should be straightforward? |
Removed endianness swapping and added PowerPC BE/LE test: (I'm not familiar with it: does this look ok?)
Adding some PowerPC people to double check
llvm/test/CodeGen/PowerPC/legalize-vaarg.ll | ||
---|---|---|
46 ↗ | (On Diff #200971) | copy and paste? |
Thanks!
llvm/test/CodeGen/PowerPC/legalize-vaarg.ll | ||
---|---|---|
46 ↗ | (On Diff #200971) | Whoops, thanks! I added in this line but looks like update_llc_test_checks.py kept it, will remove |
llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp | ||
---|---|---|
1858 ↗ | (On Diff #200974) | Why vaarg has alignment 0? I think it should be the result of getABITypeAlignment() for type of Hi? and also the alignment for Lo should not be right. |
llvm/test/CodeGen/PowerPC/legalize-vaarg.ll | ||
---|---|---|
3 ↗ | (On Diff #200974) | triple powerpc64le-unknown-linux-gnu for LE and powerpc64-unknown-linux-gnu for BE? |
llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp | ||
---|---|---|
1858 ↗ | (On Diff #200974) | Updated: I presume they should both have the same alignment? |
Building this locally with EXPENSIVE_CHECKS enabled causes a large number of warnings in the x86 test:
- Bad machine code: Missing mayStore flag ***
- function: test_large_vec_vaarg
- basic block: %bb.0 (0x25e70f4da58)
- instruction: %11:gr32 = MOV32rm %stack.0.args, 1, $noreg, 0, $noreg :: (load store 8 on %ir.args)
It looks like this happens with all vaarg expansions: The same assertions are thrown without vectors:
define i32 @test_large_vec_vaarg(i32 %n, ...) { %args = alloca i8*, align 4 %x = va_arg i8** %args, i32 ret i32 %x }
As well as on the existing vaarg tests (2008-10-29-ExpandVAARG.ll).
@RKSimon the X86 vaarg codegen tests seem to be passing now with EXPENSIVE_CHECKS enabled