[PATCH][X86] Trying to fix PR20243 - leaf frame pointer bug on X86, ELF, PIC

[Dario Domizioli]

On 5 November 2014 19:55, Rafael Espíndola <rafael.espindola at gmail.com>
wrote:

> The final lowering has to happen fairly late as the linker depends on
> doing pattern matching for optimizing the different access.
>

I see. That explains why it's expanded in AsmPrinter. And maybe even the
reason why in some cases there is also some padding between the
instructions (I imagine the linker would patch it up, right?).



> Maybe instead of having a TLS_addr64 pseudo we could have it be an
> actual call to an intrinsic and then special case the MC lowering


Hm... that would require some reworking in the places where the pseudo
instruction is handled, but it sounds like a good direction to investigate.
I'll have a look at how to implement that.

Cheers,
    Dario Domizioli
    SN Systems - Sony Computer Entertainment Group









>
> that call? That is, instead of having the X86::TLS_addr64 opcode,
> X86AsmPrinter::EmitInstruction would check the operands of a call to
> check if it should use LowerTlsAddr.
>
> On 5 November 2014 09:57, Dario Domizioli <dario.domizioli at gmail.com>
> wrote:
> > Hello llvm-dev,
> >
> > I am trying to fix PR20243.
> > The main issue seems to be that the compiler is using a
> pseudo-instruction
> > to express a TLS global access (in PIC mode on X86 ELF) and that masks
> the
> > fact that a library call has to be performed. The pseudo-instruction is
> only
> > lowered in the AsmPrinter, too late for any code that checks whether the
> > function containing the instruction is a leaf function. This affects the
> > decision whether to eliminate the frame pointer in the "eliminate frame
> > pointer only for leaf functions" case.
> >
> > I have prepared a patch, and my intention was to mark the TLS access
> > pseudo-instructions with the "isCall" flag, so that they would be
> recognized
> > as calls.
> > However I ran into a problem: the (I believe recently introduced) "FP
> > Stackify" pass tries to interpret the pseudo-instruction as a proper call
> > and it tries to get the return registers, but then it asserts because it
> > gets utterly confused by the pseudo-instruction.
> > So, to try to solve this, I had to add the "isPseudo" flag to the
> > instruction, and modify the "FP Stackify" pass to ignore call
> instructions
> > that are also pseudo (a one-line change).
> >
> > This problem suggests to me however that this is probably not the right
> way
> > to approach the original problem. It's not a good sign if I'm breaking
> > things in the process of fixing other stuff.
> >
> > I'm attaching my patch. I would gladly accept any advice on the matter.
> Am I
> > attacking the issue from the right direction? Is the "isCall" flag the
> right
> > way to express what the pseudo-instruction does? Or is the usage of a
> > pseudo-instruction itself wrong, and should it be lowered in ISel
> instead of
> > the AsmPrinter?
> >
> > Cheers,
> >     Dario Domizioli
> >     SN Systems - Sony Computer Entertainment Group
> >
> >
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141106/f8b168a1/attachment.html>