[PATCH][X86] Trying to fix PR20243 - leaf frame pointer bug on X86, ELF, PIC
Dario Domizioli
dario.domizioli at gmail.com
Mon Nov 10 07:48:36 PST 2014
Hi Rafael.
I have been looking at this for a while, but I cannot seem to find a way of
preserving an LLVM intrinsic after ISel and expanding it later.
Basically, if I add an LLVM intrinsic for TLS access in
IR/IntrinsicsX86.td, then the backend expects me to provide an instruction
selection rule for lowering it to MachineInstructions; however as you said
we cannot do it at ISel stage because we must ensure the structure is
preserved so that the linker can pattern-match it.
With "intrinsic", do you instead mean an actual function that we
manufacture on the fly in Clang (or provide a declaration for in a header),
and then eliminate / patch up in MC later on?
That might work but it seems a bit convoluted to me. Also... if we
manufacture the function, we end up with a declaration in the IR that
doesn't correspond to anything in the source; if we instead have the
function in a header, doesn't that require the user to include the header?
Is that what you're suggesting, or am I getting confused?
Cheers,
Dario Domizioli
SN Systems - Sony Computer Entertainment Group
On 6 November 2014 14:05, Rafael EspĂndola <rafael.espindola at gmail.com>
wrote:
> On 6 November 2014 09:00, Dario Domizioli <dario.domizioli at gmail.com>
> wrote:
> >
> > 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?).
>
> Correct. Some sequences use more bytes than what would be strictly
> necessary so that the linker can optimize linking a .o into a main
> executable (for example).
>
> >> 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.
>
> Thanks,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141110/767840f6/attachment.html>
More information about the llvm-commits
mailing list