Why llvm doesn't has the [target-independent] promote alloca from loop pass?

[zhaosiying12138]

I know NVPTX has implemented an llvm/lib/Target/NVPTX/NVPTXAllocaHoisting.cpp pass which can promote a compile-time-known-sized alloca op from the loop to entry bb, I think it is a very common feature, why it cannot have a target-independent version？

If it can't, would you please tell me the reason, or, I will try to commit a PR implemented by me?

[nikic]

Allocas should never (*) end up outside the entry block in the first place -- where does this show up in practice?

(*) Excluding dynamic allocas, but I assume this is not what you're talking about.

[zhaosiying12138]

Thank you nikic for your response. Yes, I think Allocas should never end up outside the entry block when I use clang to compile C code,

but I use Triton as my frontend now. Sometimes triton will generate an allocaOp in an Scf op, and I want llvm to do the hoisting.

[XChy]

AFAIK, static allocas are expected to lie in the entry block before the optimization pipeline, as passes like Mem2Reg and MoveAutoInit assume. And most frontends like clang/rust/zig obey such rules.

I know NVPTX has implemented an llvm/lib/Target/NVPTX/NVPTXAllocaHoisting.cpp pass which can promote a compile-time-known-sized alloca op from the loop to entry bb

I traced this pass back to 2012, and interestingly, I don't see any information about why this pass was set up for the NVPTX target.