[llvm] [AArch64, ELF] Allow implicit $d/$x at section beginning (PR #99718)

[Fangrui Song via llvm-commits]

MaskRay wrote:

Renamed to "implicit-mapsyms"

---

> To give you a summary of my thoughts so far:
> 
> * I don't think we'll be able to change the AArch64 ABI as I don't think there's enough consensus on the GNU side for a relocatable object based solution.

Ack.

> * An alternative, likely LLVM only, opt-in option for users with large projects, in control of their own toolchain to reduce mapping symbols could be valuable to those projects.

Looks good. 

> * I'd like to discourage use of the opt-in option where portability of the relocatable objects is a concern. For example, while there are no plans to do so, I couldn't guarantee the AArch64 ABI might make changes that would retain backwards compatibility.

I agree with your point about discouraging its use where portability is crucial.

Does the last sentence read as: the AArch64 ABI might make changes to break backwards compatibility. But with what?

As is, the proposed `implicit-mapsyms` option is non-conforming per
"A section that contains instructions must have a mapping symbol defined at the beginning of the section. If a section cont     ains only data no mapping symbol is required.

I agree that users of the opt-in option should well understand the risks.

> * If the option becomes LLVM only then I'd prefer we gave the option a more neutral name. For example `-mimplicit-mapsyms` or `-malternative-mapsyms` as `-moptimize-mapsyms` doesn't imply a, small, trade-off in portability.

Looks good.
The MCTargetOption/cl::opt option (for llc/llvm-mc) has been renamed to `implicit-mapsyms`.
Another patch will be needed to add a driver option, perhaps `-Wa,-mimplicit-mapsyms`.

> * I'd like to see the help for the option mention compatibility. For example "Allow mapping symbol at section beginning to be implicit, lowers number of mapping symbols at the expense of some portability. Recommended for large projects that can build all their objects using this option."

Thanks for the suggestion. Improved the message at `llvm/lib/MC/MCTargetOptionsCommandFlags.cpp`.

> * I'd like to find a way of recording that implicit mapping symbols have been used, I don't think we need a compatibility check.

Looks good. Recording the mapping symbol scheme might depend on `SHT_AARCH64_ATTRIBUTES`, which has no GNU/LLVM toolchain implementation yet.

> https://github.com/llvm/llvm-project/pull/99718#issuecomment-2286565171 While I don't want to speculate too much over how to mark an object, I'm wondering if it is something you're willing to entertain?

Yes, I'm open to exploring that once the base mechanism is available.


https://github.com/llvm/llvm-project/pull/99718