Open Emilgardis opened 1 year ago
@ecnelises @bzEq you are target maintainers for powerpc64 (which is a different arch but hopefully similar enough) so you may have opinions or know something. our target maintainer documentation is absolutely abysmal so I was not able to find anyone else. lol.
@Emilgardis The warning you see is because not all target features LLVM offers "make sense" in the Rust Cinematic Universe in terms of target features, and also we want to be able to have Rust's target features continue making sense and be something resembling supported if you e.g. use the Cranelift codegen backend (for targets that Cranelift supports). Thus we try to collect them as explicit additions to the compiler, thus we set this warning to prompt people to complain about it (and thus find out which features people actually want suport for).
However, the PowerPC targets should be using hard floats by default, shouldn't they? Why are you manually configuring this feature?
[...] thus we set this warning to prompt people to complain about it (and thus find out which features people actually want suport for).
perfect, makes sense
Seems then that the powerpc-unknown-linux-musl
target is wrong, doesn't seem to specify -hard-float
edit: misread your question!
the device we want is a openwrt router that doesn't support hardfloats, MPC8540
Oh, it's a negation! I somehow missed that. That makes sense. I think we'd want to support the total configuration, at least hypothetically, though it implies more exciting adventures in float ABIs.
Wait, that has an e500 core, doesn't it?
The PowerPC e500 is a 32-bit microprocessor core from Freescale Semiconductor. The core is compatible with the older PowerPC Book E specification as well as the Power ISA v.2.03. It has a dual issue, seven-stage pipeline with FPUs (from version 2 onwards)
Not the e500v2, I take it?
@thomas725 can you correct me on the model/arch of the device you're targetting?
We shouldn't allow any more float-ABI-affecting target features without a way to ensure ABI compatibility. Softloat and hardfloat mode are not ABI-compatible on many targets since they pass float types in different registers. Is that the case on PowerPC as well? If yes, then either they need to be two different targets, or we need to reject calling functions that take f32
/f64
by-val arguments when hardfloat support is absent.
My initial thought was maybe we'd want powerpc (32-bit) targets to default to softfloat.
Won't that make extern "C"
incompatible with the usual C ABI on that target?
Softloat and hardfloat mode are not ABI-compatible on many targets since they pass float types in different registers. Is that the case on PowerPC as well?
Yes. PowerPC hard float uses FPR, while soft float uses GPR.
We shouldn't allow any more float-ABI-affecting target features without a way to ensure ABI compatibility.
IIUC this is to avoid linking objects compiled with different float ABIs (since Rust has no way differentiate them)?
Anyway, making soft float as default for 32-bit ppc is not a good idea.. Even powerpcspe
has hard float enabled by default.
IIUC this is to avoid linking objects compiled with different float ABIs (since Rust has no way differentiate them)?
Yes. Rust has a way to differentiate them - it's target triples.
I know some targets (arm? riscv?) encode float ABI into their triples, which makes sense. BTW encoding float ABI in .gnu_attribute
(supported partially by LLVM) may also help in such scenario because linker would refuse linking objects with different attribute value.
@Emilgardis it's a TP-Link TL-WDR4900 v1.x featuring a Freescale P1014 MPC85xx SoC. (sorry for the late response)
perfect, that seems to be e500v1 which does have SPE instructions but doesn't feature a FPU. So, I think this issue can be closed as for our specific purpose we should use the target powerpc-unknown-linux-muslspe
or possibly powerpc-unknown-linux-musleabispe
for that target, I think
# powerpc-unknown-linux-musleabispe.json
{
"arch": "powerpc",
"crt-objects-fallback": "musl",
"crt-static-default": false,
"crt-static-respected": true,
"data-layout": "E-m:e-p:32:32-Fn32-i64:64-n32",
"dynamic-linking": true,
"env": "musl",
"has-rpath": true,
"has-thread-local": true,
"linker-flavor": "gnu-cc",
"llvm-target": "powerpc-unknown-linux-muslspe",
"max-atomic-width": 32,
"os": "linux",
"position-independent-executables": true,
"pre-link-args": {
"gnu-cc": [
"-m32 -mspe"
],
},
"relro-level": "full",
"stack-probes": {
"kind": "inline"
},
"supported-split-debuginfo": [
"packed",
"unpacked",
"off"
],
"target-endian": "big",
"target-family": [
"unix"
],
"target-mcount": "_mcount",
"target-pointer-width": "32"
}
is correct. Will have to experiment (I'll update this comment also if a better spec is needed)
However, the question about powerpc-unknown-linux-musl
supporting -hardfloat
remains, I think the consensus in this issue is that it should be done in another target: powerpc-unknown-linux-muslsf
.
RUSTFLAGS="-C target-feature=-crt-static,-hard-float" cargo +nightly build --release --target powerpc-unknown-linux-musl
gives the warning
while it should be supported by llvm
is the error supposed to happen or is this expected?
cc https://github.com/cross-rs/cross/issues/1363