[PATCH] D73664: [PowerPC][Future] Add Support For Functions That Do Not Use A TOC.

[Stefan Pintilie via Phabricator via llvm-commits]

stefanp marked an inline comment as done.
stefanp added inline comments.


================
Comment at: llvm/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.cpp:177
+    // indicates a an offset of 0 but indicates that r2 is preserved.
+    if (Res != 1 && Res != ELF::decodePPC64LocalEntryOffset(Encoded))
       report_fatal_error(".localentry expression cannot be encoded.");
----------------
sfertile wrote:
> stefanp wrote:
> > sfertile wrote:
> > > Can `Res` be evaluated to 1? It has a very special meaning: The local and global entry points are the same, and r2 should be treated as caller-saved for callers. I'm not aware of LLVM having support for that yet but I could be mistaken. If it does already have support do we have a lit test for it?
> > Yes, we can now have Res equal to 1. We did not have support for this before but we need support for this for the implementation of PCRelative. If a function has no uses of R2 but does have function calls with the `@notoc` relocation we need to use an st_other=1 for it.
> > Yes, we can now have Res equal to 1. We did not have support for this before but we need support for this for the implementation of PCRelative. 
> 
> My question wasn't "do we need to support an encoding of 1".  I understand we do now need to support this. My question was can Res be evaluated to '1' which I think the answer here is **no**.  I'll provide my reasoning why I think so and you can correct me if I am wrong.
> 
> We evaluate 'Res' through a generic interface in MCExpr. The MCExpr we build for the local offset is [[ https://github.com/llvm/llvm-project/blob/b198f16e1e1c8ee849008c1b886199eae5bc2e01/llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp#L1518 | here ]]. As you can see it is a subtract of the  global entry label from the local entry label. I haven't went into `MCExpr::evaluateAsAbsolute` to verify but I doubt it has the context to determine if this subtract expression should be replaced by '1' instead of naively evaluating the subtraction.
> 
> A further complication is that we don't call `emitLocalEntry` if we don't use X2. I don't know what our intended behavior would be if we have a function that doesn't use X2 but has multiple @notoc calls. If we should encode '1' in ST_OTHER in that case, then we need to do so elsewhere.
I did discuss this with Sean offline but I want to add more information here for everyone else:
An `st_other` value of 1 is a special value and does not behave like the others. Normally an assembly file will have
`.localentry @symbol, .LEP-.GEP` where LEP is the local entry point and GEP is the global entry point. The linker can then compute that difference and assign `st_other` accordingly. However, for the case of 1 there is a problem because we will never have the local entry and the global entry one byte apart. That was the issue that Sean was talking about.
However, this patch also adds code to `PPCLinuxAsmPrinter::EmitFunctionBodyStart` where we introduce the assembly 
`.localentry @symbol, 1` for just this situation.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73664/new/

https://reviews.llvm.org/D73664