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

Tue May 12 03:43:29 PDT 2020

jonpa added a comment.

In D79589#2031116 <https://reviews.llvm.org/D79589#2031116>, @serge-sans-paille wrote:

> 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)

In theory, all uses must have a prior definition in the IR model, and it is a broken IR if there is not. If there is a use in an MBB of a value defined in another MBB that is not an immediate predecessor, but further up in the CFG, that should be marked as live-in to MBB and also live-in to any other MBB that is on the path to the use (to model "live-through"). The machine verifier already has checks for this, and it is under development: https://reviews.llvm.org/D78586.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79589