[PATCH] D79589: [WIP] syndicate code generation between dynamic alloca and static alloca during stack clash probing

serge via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue May 12 03:11:26 PDT 2020


serge-sans-paille added a comment.

In D79589#2029519 <https://reviews.llvm.org/D79589#2029519>, @jonpa wrote:

> In D79589#2029464 <https://reviews.llvm.org/D79589#2029464>, @serge-sans-paille wrote:
>
> > > All the callee-saved registers are added as live-in on the entry block, of which most are saved (and killed) immediately on SystemZ. The function argument registers however are also live-in and as well live past the stack-probing loop. I found it most convenient to make those argument registers in particular live-in after the probing by recomputing the liveness...
> >
> > I've got no prior knowledge of SystemZ, so pardon the seemingly stupid question, but how does the live-in of the entryblock impacts the Live-in of the probing loop?
>
>
> There are no stupid questions here :-)  Well, the entry block is split at the point of the stub, with new MBBs inserted in between those two new halves. So my understanding is that any phys reg that is live at the point of the stub should also be live after it (in the rest of the original MBB), and therefore it should be live-in to all the other new blocks created so that the regs are proberly modelled as live-through through those blocks...


I can't find a reference in the doc that states whether Live-In for a block include live-In of its successors (which you seem to imply) or only of the block itself (which was my original belief)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79589/new/

https://reviews.llvm.org/D79589





More information about the llvm-commits mailing list