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

Rafael EspĂ­ndola rafael.espindola at gmail.com
Mon Nov 10 13:02:39 PST 2014


On 10 November 2014 10:48, Dario Domizioli <dario.domizioli at gmail.com> wrote:
> 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?

Sorry, you were right. This has to be an instruction, it is too late
to have an intrinsic.

Your change to add a isCall is probably also correct. The problem with
TLS_addr64 is that it has not been upgraded to use the new call
representation with register masks.

Probably the best example of how this should work is what AArch64 does:

-----------------------------------------------------------------------
let isCall = 1, Defs = [LR] in
def TLSDESC_BLR
    : Pseudo<(outs), (ins GPR64:$dest, i64imm:$sym),
             [(AArch64tlsdesc_call GPR64:$dest, tglobaltlsaddr:$sym)]>;
------------------------------------------------------------------------

so it has isCall, but not the explicit Defs list. It is created with

-------------------------------------
  const uint32_t *Mask = ARI->getTLSCallPreservedMask();
....

  SmallVector<SDValue, 6> Ops;
  Ops.push_back(Chain);
  Ops.push_back(Func);
  Ops.push_back(SymAddr);
  Ops.push_back(DAG.getRegister(AArch64::X0, PtrVT));
  Ops.push_back(DAG.getRegisterMask(Mask));
  Ops.push_back(Glue);

  SDVTList NodeTys = DAG.getVTList(MVT::Other, MVT::Glue);
  Chain = DAG.getNode(AArch64ISD::TLSDESC_CALL, DL, NodeTys, Ops);
--------------------------------------

With this X86FloatingPoint.cpp should not get confused about
__tls_get_addr returning a value in the fp stack.

Cheers,
Rafael



More information about the llvm-commits mailing list