The Target::abi_required_features and Target::check_consistency ABI-checking logic currently has no handling for Arch::Sparc64.
For context: on other targets this logic ensures things like
- valid values for
llvm_abiname/llvm_floatabi
- consistent values for
cfg_abi relative to llvm_abiname
- preventing target features from being enabled/disabled in a way that would alter the ABI
This is needed to prevent issues like #116344.
We have two tier 2 target for that architecture:
And a few tier 3 targets:
To resolve this issue, we need to figure out whether there are any ABI differences between those targets, how LLVM determines which ABI to use, an how we can ensure that only code with a consistent ABI is ever linked together. The existing logic for abi_required_features and check_consistency is probably instructive to see how this is done for other targets.
Looking at the LLVM source code, the only "obviously" ABI-affecting target feature I was able to identify is the usual soft-float. So the "obvious" thing to do would be to mark that target feature as "forbidden" in abi_required_features, and maybe eventually add a soft-float target if anyone needs that. But maybe there is more?
Cc @psumbera @kulikjak @workingjubilee
The
Target::abi_required_featuresandTarget::check_consistencyABI-checking logic currently has no handling forArch::Sparc64.For context: on other targets this logic ensures things like
llvm_abiname/llvm_floatabicfg_abirelative tollvm_abinameThis is needed to prevent issues like #116344.
We have two tier 2 target for that architecture:
And a few tier 3 targets:
To resolve this issue, we need to figure out whether there are any ABI differences between those targets, how LLVM determines which ABI to use, an how we can ensure that only code with a consistent ABI is ever linked together. The existing logic for
abi_required_featuresandcheck_consistencyis probably instructive to see how this is done for other targets.Looking at the LLVM source code, the only "obviously" ABI-affecting target feature I was able to identify is the usual
soft-float. So the "obvious" thing to do would be to mark that target feature as "forbidden" inabi_required_features, and maybe eventually add a soft-float target if anyone needs that. But maybe there is more?Cc @psumbera @kulikjak @workingjubilee