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

[Rafael Espíndola]

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

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