en Copyright 2015 Java http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/RISCV/rvv/wrong-stack-offset-for-rvv-object.mir#cb8681a2 [RISCV] Fix RVV stack frame alignment bugsThis patch addresses several alignment issues in the stack frame whenRVV objects are taken into account.One bug is that the RVV stack was never guaranteed to keep the alignmentof the stack *as a whole*. We must maintain a 16-byte aligned stack atall times, especially when calling other functions. With the standard Vextension, this is conveniently happening since VLEN is at least 128 andalways 16-byte aligned. However, we support Zvl64b which does notguarantee this. To fix this, the RVV stack size is rounded up to bealigned to 16 bytes. This in practice generally makes us allocate astack sized at least 2*VLEN in size, and a multiple of 2. |------------------------------| -- <-- FP | 8-byte callee-save | | | |------------------------------| | | | one VLENB-sized RVV object | | | |------------------------------| | | | 8-byte local variable | | | |------------------------------| -- <-- SP (must be aligned to 16)In the example above, with Zvl64b we are decrementing SP by 12 byteswhich does not leave SP correctly aligned. We therefore introduce anextra VLENB-sized amount used for alignment. This would therefore ensurethe total stack size was 16 bytes (48 for Zvl128b, 80 for Zvl256b, etc): |------------------------------| -- <-- FP | 8-byte callee-save | | | |------------------------------| | | | one VLENB-sized padding obj | | | | one VLENB-sized RVV object | | | |------------------------------| | | | 8-byte local variable | | | |------------------------------| -- <-- SPA new RVV invariant has been introduced in this patch, which is that thebase of the RVV stack itself is now always aligned to 16 bytes, not 8 asbefore. This keeps us more in line with the scalar stack and should beeasier to reason about. The calculation of the RVV padding has thuschanged to be the amount required to align the scalar local variablesection to the RVV section's alignment. This amount is further roundedup when setting up the initial stack to keep everything aligned: |------------------------------| -- <-- FP | 8-byte callee-save | |------------------------------| | | | RVV objects | | (aligned to at least 16) | | | |------------------------------| | RVV padding of 8 bytes | |------------------------------| | 8-byte local variable | |------------------------------| -- <-- SPIn the example above, it's clear that we need 8 bytes of padding to keepthe RVV section aligned to 16 when using SP. But to keep SP *itself*aligned to 16 we can't decrement the initial stack pointer by 24 - wehave to round up to 32.With the RVV section correctly aligned, the second bug fixed bythis patch is that RVV objects themselves are now correctly aligned. Wewere previously only guaranteeing an alignment of 8 bytes, even if theyrequired a higher alignment. This is relatively simple and in practicewe see more rounding up of VLEN amounts to account for alignment inbetween objects: |------------------------------| | RVV object (aligned to 16) | |------------------------------| | no padding necessary | |------------------------------| | 2*VLENB RVV object (align 16)| |------------------------------| | VLENB alignment padding | |------------------------------| | RVV object (align 32) | |------------------------------| | 3*VLENB alignment padding | |------------------------------| | VLENB RVV object (align 32) | |------------------------------| -- <-- base of RVV sectionNote that a lot of the regressions in codegen owing to the new alignmentrules are correct but actually only strictly necessary for Zvl64b (andZvl32b but that's not really supported). I plan a follow-up patch totake the known VLEN into account when padding for alignment.Reviewed By: StephenFanDifferential Revision: https://reviews.llvm.org/D125787 List of files: /llvm-project-15.0.7/llvm/test/CodeGen/RISCV/rvv/wrong-stack-offset-for-rvv-object.mir Mon, 16 May 2022 09:57:32 +0000 Fraser Cormack <fraser@codeplay.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/RISCV/rvv/wrong-stack-offset-for-rvv-object.mir#2b0fedc2 [RISCV] Print human-readable VTYPE/SEW/LMUL in MIRThis patch adds custom MIR operand comments to VTYPE immediate operandsin VSETVLI instructions and SEW/LMUL operands in vector codegen pseudoinstructions. The result is intended to be more human-readable andhopefully maintainable when working with MIR, particularly whenwriting or reading test cases.Reviewed By: craig.topperDifferential Revision: https://reviews.llvm.org/D124187 List of files: /llvm-project-15.0.7/llvm/test/CodeGen/RISCV/rvv/wrong-stack-offset-for-rvv-object.mir Wed, 03 Nov 2021 11:41:03 +0000 Fraser Cormack <fraser@codeplay.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/RISCV/rvv/wrong-stack-offset-for-rvv-object.mir#9c5aedfb [RISCV] Fixing stack offset for RVV object with vararg in stack.We found LLVM generate wrong stack offset for RVV object when stackhaving variable argument, that cause by we didn't count vaarg part duringcalculate RVV stack objects.Also update the stack layout diagram for including vaarg in the diagram.Stack layout ref:https://github.com/gcc-mirror/gcc/blob/master/gcc/config/riscv/riscv.cc#L3941Reviewed By: rogfer01Differential Revision: https://reviews.llvm.org/D123180 List of files: /llvm-project-15.0.7/llvm/test/CodeGen/RISCV/rvv/wrong-stack-offset-for-rvv-object.mir Tue, 05 Apr 2022 15:29:37 +0000 Kito Cheng <kito.cheng@sifive.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/CodeGen/RISCV/rvv/wrong-stack-offset-for-rvv-object.mir#7a123890 [RISCV] Pre-commit for fixing stack offset for RVV objectReviewed By: rogfer01, frasercrmckDifferential Revision: https://reviews.llvm.org/D123179 List of files: /llvm-project-15.0.7/llvm/test/CodeGen/RISCV/rvv/wrong-stack-offset-for-rvv-object.mir Wed, 06 Apr 2022 01:51:09 +0000 Kito Cheng <kito.cheng@sifive.com>