Nat! via llvm-dev
2015-Sep-03 15:57 UTC
[llvm-dev] Rerunning TailCallElim at a later stage
Hi from what I have figured out, the pass "TailCallElim" is being done in what I would call the "opt" phase of optimization. The "StackColoring" is being done in the "llc" phase. opt -> llc, so TailCallElim is always ahead. Now I would like to add something (my reusealloca idea) in "StackColoring" to get rid of some allocas, which inhibit "TailCallElim". * Is it possible to rerun (if even possible at that stage) the "TailCallElim" at this stage ? * Is it possible to make "StackColoring" into an "opt" pass and try to get it ahead of "TailCallElim" ? I guess not, though I can see how "RegisterColoring" is dependent on architecture, but I don't really see it for allocas. Ciao Nat! P.S. AU.addRequired<TailCallElim>(); would not work BTW.
Reid Kleckner via llvm-dev
2015-Sep-03 16:18 UTC
[llvm-dev] Rerunning TailCallElim at a later stage
No, this reordering is not possible. Stack coloring is part of codegen. Passes that modify the IR cannot run as part of codegen. Your best bet for enabling tail calls with your meta calling convention is to write a custom pass that rewrites calls in the tail position to use the incoming argument memory instead of a local alloca. It would be up to this custom pass to determine exactly when this is legal. On Thu, Sep 3, 2015 at 8:57 AM, Nat! via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Hi > > from what I have figured out, the pass "TailCallElim" is being done in > what I would call the "opt" phase of optimization. The "StackColoring" is > being done in the "llc" phase. opt -> llc, so TailCallElim is always ahead. > > Now I would like to add something (my reusealloca idea) in "StackColoring" > to get rid of some allocas, which inhibit "TailCallElim". > > * Is it possible to rerun (if even possible at that stage) the > "TailCallElim" at this stage ? > > * Is it possible to make "StackColoring" into an "opt" pass and try to get > it ahead of "TailCallElim" ? I guess not, though I can see how > "RegisterColoring" is dependent on architecture, but I don't really see it > for allocas. > > Ciao > Nat! > > P.S. AU.addRequired<TailCallElim>(); would not work BTW. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150903/217d4d3c/attachment.html>
Nat! via llvm-dev
2015-Sep-03 16:47 UTC
[llvm-dev] Rerunning TailCallElim at a later stage
Reid Kleckner schrieb:> Your best bet for enabling tail calls with your meta calling convention > is to write a custom pass that rewrites calls in the tail position to > use the incoming argument memory instead of a local alloca. It would be > up to this custom pass to determine exactly when this is legal.I assume that would be a pass that I would try to get, somehow, ahead of "TailCallElim" in the "opt" phase ? Thanks for the help! Ciao Nat!
Seemingly Similar Threads
- [LLVMdev] [PATCH] Minor fix to StackColoring to avoid needlessly clearing mem operands.
- [LLVMdev] Fwd: [PATCH] Minor fix to StackColoring to avoid needlessly clearing mem operands.
- [LLVMdev] [PATCH] Minor fix to StackColoring to avoid needlessly clearing mem operands.
- Unexpected behavior found in Stack Coloring pass, need clarification
- [LLVMdev] StackColoring remaps debug info from unrelated functions