Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp | ||
---|---|---|
97 | Should hasFP not pessimistically return true if V is enabled? |
llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp | ||
---|---|---|
97 | Do you mean to move Subtarget.hasStdExtV() into hasFP()? To consider spilling, it seems reasonable. |
llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp | ||
---|---|---|
97 | Yeah, that's what I meant. I believe I had a thought a few hours after that comment why you might not want hasStdExtV in hasFP, but I've forgotten it now. |
llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp | ||
---|---|---|
851 | Use if/else here. The conditional operator with no assignment looks kind of strange. | |
858 | Same here | |
llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp | ||
97 | I don't see an equivalent of this in AArch64 when SVE is enabled. How are the avoiding needing a frame pointer? |
llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp | ||
---|---|---|
97 | Indeed, it is possible to access frame objects without reserving frame pointer when there is any RVV objects on the stack. If we do not leverage frame pointer when there is any RVV objects, all frame object accesses will need do some polynomial calculation. Now, there is a new type to represent two dimensions stack offset. I could try to implement it without reserving the frame pointer. |
llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp | ||
---|---|---|
97 | Being deep within hasFP code right now, and seeing that it has some nasty edge-cases when introducing ilp32e, it seems prudent to start with a conservatively correct approach for the initial implementation, and then optimise to avoid using frame pointers if necessary? That should also make reviewer's lives easier :) |
Use if/else here. The conditional operator with no assignment looks kind of strange.