In the Small code-model the linker will allocate multiple TOC bases for modules with TOCs that overflow a 16 byte offset. If this happens then all the issues with cross-module calls apply to calls within the same module but with different TOC bases. Since we don't know at compile time where the linker will decide to split the module we can only treat calls within the same section as 'local'. The medium and large code models are expected to provide a sufficiently large TOC to provide all data addressing needs of a module with a single TOC, and so we only need to check if a callee is local to the same module as the caller.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/Target/PowerPC/PPCISelLowering.cpp | ||
---|---|---|
4342 | Should we just move the code from this function to the existing resideInSameSection() function and rename the function itself? I see in there we're also checking GlobalAddressSDNode *G = dyn_cast<GlobalAddressSDNode>(Callee); if (!G) return true; |
lib/Target/PowerPC/PPCISelLowering.cpp | ||
---|---|---|
4342 | I think that is a good suggestion. I can't think of any other reason we would want to see if 2 symbols reside in the same section other then if they share a TOC base. I'll update it. |
lib/Target/PowerPC/PPCISelLowering.cpp | ||
---|---|---|
4342 | I agree. Both calls to this function are really after the same thing. Although I find this name just slightly misleading. Perhaps something like mayHaveDifferentTOCs() or callRequiresTOCRestoreNop(). | |
test/CodeGen/PowerPC/ppc64-blnop.ll | ||
82 | Well, I think it would be more appropriate to include the call opcode as well - I imagine this one would be bl. | |
test/CodeGen/PowerPC/ppc64-calls.ll | ||
28 | This comment is misleading. It almost seems to imply that with the large and medium code model, a weak definition can't be overridden in a different module. You should probably say something like "With the large and medium code models, both definitions will have the same TOC since they won't reside in different DSO's." Or something along those lines. |
lib/Target/PowerPC/PPCISelLowering.cpp | ||
---|---|---|
4352 | codemodel should either be "code model" or "CodeModel". My preference is to just write this in English, "small code model", with no extra capitalization. | |
4353 | This does not explain why this cannot happen for the other code models. The ABI is a bit ambiguous here, saying "The medium code model is expected to provide a sufficiently large TOC to provide all data addressing needs of a module with a single TOC." Expected, however, does not mean "must". We need to supplement here with some additional explanation of what existing linkers actually do (e.g. that neither ld.bfd nor ld.gold will create multiple TOCs for anything other than the small code model, regardless of what might be theoretically allowed). | |
4354 | I don't see exactly how this reference is relevant. There is some explanation of why you can't tail call to functions in other modules, but if that's not explained in the comments in this file, we should do that directly. |
lib/Target/PowerPC/PPCISelLowering.cpp | ||
---|---|---|
4353 | I'm going to send an email to Alan Modra to verify my understanding of the behavior for medium and large code models is correct for both gold and ld. I'll update this comment to reflect that once I get an answer. |
lib/Target/PowerPC/PPCISelLowering.cpp | ||
---|---|---|
4252 | In my understanding, ELFv1 uses small code model (please consult with ABI document). If so we need to check ELFv2 ABI. |
lib/Target/PowerPC/PPCISelLowering.cpp | ||
---|---|---|
4252 | I thought the V1 ABI used small code model for 32 bit and medium code model for 64 bit, but I'll double check. |
lib/Target/PowerPC/PPCISelLowering.cpp | ||
---|---|---|
4273 | What happened before binutils 2.24? 2.24 is only about 3.5 years old. |
lib/Target/PowerPC/PPCISelLowering.cpp | ||
---|---|---|
4252 | I dug through the 'V1.9 64 bit ELF ABI supplement ' as well as the older '[32-bit] PowerPC Processor Supplement' and neither mention what code model should be used by default. I think I originally used the gcc docs to infer that ppc64 defaults to medium code model: IBM RS/6000 and PowerPC Options
and then found 'adjustCodeGenOpts' in PPCMCTargetDesc.cpp which confirmed it. |
lib/Target/PowerPC/PPCISelLowering.cpp | ||
---|---|---|
4252 | Sure. Thanks! |
lib/Target/PowerPC/PPCISelLowering.cpp | ||
---|---|---|
4273 | I don't know. I asked what the behavior of the 2 linkers was if the TOC grows larger then the 32 bit offset, as well as checking that 'module' in the abi text meant entire exe and entire shared-object (rather then just a single object file). I assumed that the behavior change in 2.24 was from generic linker error to specific diagnostic rather then add new toc base --> error. I can follow up though to ensure this is the case. |
Simplified the codemodel check since Default and JitDefault code models were removed.
lib/Target/PowerPC/PPCISelLowering.cpp | ||
---|---|---|
4273 | Before the change in 2.24 if the offset for *_HI and *_HA relocs didn't fit in 32 bits a 4 instruction sequence would be used to build a 64 bit constant. The change added the 32 bit limit and overflow checking to the *_HI and *_HA relocs and added *_HIGH and *_HIGHA relocs to be used if a 64 bit offset may be needed. So even with the old behavior, its still a single TOC base. |
In my understanding, ELFv1 uses small code model (please consult with ABI document). If so we need to check ELFv2 ABI.