[llvm-dev] Register spilling in caller saved backend

Bruce Hoult via llvm-dev llvm-dev at lists.llvm.org
Tue Sep 1 10:13:34 PDT 2015


Note that it would be very unusual to have no callee saved registers.

Historically (pre-RISC), it was normal to pass arguments on the stack and
have ALL registers callee saved. Or maybe to have just one or two registers
that could be clobbered by the called function, or linkage code.

On Tue, Sep 1, 2015 at 7:01 PM, Peter Bergner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Tue, 2015-09-01 at 08:52 -0700, Jacques Pienaar via llvm-dev wrote:
>
> > int main() {
> >   for (int i = 0; i < 10; ++i) {
> >     foo();
> >   }
> > }
> >
> >
> > The resultant output code spills 'i' within the loop (I have to
> > compile with -fno-unroll-loops else the loop and 'i' gets optimi! zed
> > away) while 'i' is assigned to a register that is used nowhere else in
> > the generated program and I would consider 'foo' easy to analyse. At
> > the call site of 'foo' the debugging output reports that the stack
> > pointer and return value registers are "imp-use" and "imp-def" and no
> > other registers are used.
>
> When a function (such as main() in this case) is compiled, all calls to
> functions are assumed to clobber all caller saved registers.  Since your
> backend said that all registers are caller saved, then the compiler has
> not choice but to spill 'i' around the call to foo(), since it may
> trash the register 'i' is allocated to.
>
>
> > Should the spilling have occurred? Or this due to some feature in the
> > backend that is missing?
>
> This is totally as expected when you have no callee saved registers.
>
>
> Peter
>
>
> _______________________________________________
> 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/20150901/b1a78918/attachment.html>


More information about the llvm-dev mailing list