[LLVMdev] Shrink Wrapping - RFC and initial implementation

John Mosby ojomojo at gmail.com
Thu Feb 26 17:52:15 PST 2009


Hi Anton,
Thanks for your questions, that's what I'm looking for.

On Thu, Feb 26, 2009 at 5:33 PM, Anton Korobeynikov <anton at korobeynikov.info
> wrote:

> Hello, John
>
> > My limited implementation uses a workaround that adjusts the
> > generation of prologue code and the frame indices used by
> > the target eliminateFrameIndex() when necessary. I am looking at
> > several approaches, but I would like input from anyone who
> > has an opinion.
> I haven't looked into the patch deep enough yet, but I have at least 2
> questions:
> 1. How do all the stuff play with dynamic stack realignment?
> 2. It seems, that dwarf information about callee-saved registers is
> invalidated by your patch.
> This means, that you won't have sane stack traces in the debugger.
> Unwinding won't also work.
> Have you tried to compile some C++ code, which uses EH?


Integrating shrink wrapping with dynamic stack realignment, debugging info,
EH (and more)
requires a more general (or more complete) way of treating callee-saved
registers, and I did
not attempt to tackle this in the patch. I meant to show a starting point
for this work and get
some questions coming in (working so far :-)).

I am not far along enough with the two approaches I'm looking at to give
more detail. I will
have more worked out in a few days.

I'm still coming up to speed in the code generator areas, so thanks for your
patience!

Again, thanks for your questions,
John


>
> --
> With best regards, Anton Korobeynikov.
>
> Faculty of Mathematics & Mechanics, Saint Petersburg State University.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090226/20ae0327/attachment.html>


More information about the llvm-dev mailing list