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

[Sean Fertile via Phabricator via llvm-commits]

sfertile 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.");
----------------
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.


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

https://reviews.llvm.org/D73664