Issues with soft float

1

Hi guys, I’m a rust newbie who has been exploring bare metal rust. I’ve been reading a lot of the RFCs, PRs, etc., and there seems to be some possible misunderstandings regarding soft float. I guess I’m sharing my thoughts here as a pre-RFC pre bug report type thing. Please let me know if you think I should raise an issue or RFC relating to any of this.

Issue 1

The rustc codgen option soft-float -- generate software floating point library calls is incorrect, looking at the source you can see it has nothing to do with generating software floating point calls (which you get with target-feature codegen option), rather it changes the floating point ABI. This leads to expectations that something like this should work.

Possible solutions:

  • Fix the doc to say: “soft-float -- force use of soft float ABI (this will likely make this link incompatible with everything else including core)”

  • Make the option mirror llvm correctly by: "float-abi=type -- set the float ABI default, soft or hard" This is potentially a breaking change. (My preferred option)

  • Add the above but leave the former as an undocumented deprecated option to prevent a breaking change.

  • Get rid of the option entirely. It is a fairly useless option because it makes you incompatible with any other crate including core, std. Although I guess it could be useful if you are not linking anything with floats.

Issue 2

The target configuration json has no way to specify the float ABI so you are stuck with the default of the triple. This is fine for arm, which has the float ABI is specifiable with the triple but, AFAIK, is not possible for aarch64, x86-64 and others. This leads to the need for things like float-free core because you can’t specify a soft float ABI on all targets.

Solution:

  • Add float-abi to target configuration with a default value of default so nothing breaks

Appendix

The use case for a lot of this is kernel development without using floating point registers. To ensure this you need to use a soft float ABI and make sure no floating point code is generated. The latter is done with target-feature, from my experiments these are the target features needed but I’m sure you could look in llvm source to see exactly which.

  • x86-64 -mmx,-sse,+soft-float
  • aarch64 -fp-armv8
  • arm +soft-float
1 Like
2

Fixing the documentation to note that the -C soft-float option messes with the ABI seems fine; patch welcome. Renaming the option doesn’t really seem productive.

The lack of soft-float targets for x86 and aarch64 in Rust isn’t just a configuration problem; LLVM doesn’t support it.

3

Renaming the option doesn't really seem productive.

The advantage is it lets you specify hard float on a soft float by default option.

The lack of soft-float targets for x86 and aarch64 in Rust isn't just a configuration problem; LLVM doesn't support it.

AFAIK it does, what makes you think otherwise?

4

Err, the fact that there isn't any soft-float calling convention, for one? That's why people trying to use soft-float on x86-64 are running into errors in the first place.

5

Err, the fact that there isn't any soft-float calling convention

Maybe not an "official" one I guess, but LLVM seems to support one, like it does many other non-"official" calling conventions.

6

I’ve tried the +soft-float feature and it works without problems on x86_64, even with -mmx,-sse. The compiler emits no xmm instructions and floating point code still works.

However, it seems like the -C soft-float option isn’t needed at all. It still works fine without it…

7

Ah yes, it seems you are quite right. I checked arm and aarch64 too. Obviously you must have a soft float ABI if you're not using floating point registers, but I was expecting LLVM to give an error rather than change to using soft float ABI. It turns out, even if you specify hard float ABI with all the FP regs turned off it just uses a soft float ABI without giving any error.

I still think it's probably better adding float ABI to the target json in case it ever does become an error, but I am not so concerned anymore.

8

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.