-mlong-double-64

[markschimmel]

I would like to support option -mlong-double-64 for RISC-V to make type long double a 64-bit type aligned to 64-bits just like type double. I'd then like to record in the ELF file that I compiled my code this way and have the linker perform consistency checking. I assume the best option is to add a non-standard attribute (>= 32768) and record this value in the .riscv.attributes section. Is it better to ask for a standard attribute tag for this purpose instead of using a non-standard tag? If I should us a non-standard tag, is there a policy for allocating a specific number? Thanks

[aswaterman]

Out of curiosity, I checked how this works on x86-64/Linux, and it seems there is no protection at all: the C++ name mangling for 64b and 80b long doubles is the same, and nothing special ends up in the ELF, so code links fine then produces the wrong answer at runtime. Not ideal.

IMO, if we think that GCC/Clang support for -mlong-double-64 is worth adding, then a standard attribute is also worth adding.

[jrtc27]

Neither GCC nor Clang support it for AArch64, so I question how useful the option is in reality.

[MaskRay]

I added -mlong-double-128 to Clang and made related fixes (e.g. https://reviews.llvm.org/D64277).

On x86, both -mlong-double-64 and -mlong-double-80 use e for long double. Agreed that this is not great.

I question the usefulness as well. If a user doesn't want to provide long double implementations, it might be better to audit the code base and do string replacement.

[aswaterman]

I know SiFive looked into this topic a few years ago, as a means of reducing the code size of the standard library for embedded systems, but IIRC, we found that we were able to do a sufficient job with library-level changes only. @kito-cheng might have more to say on that.

[markschimmel]

My personal justification is that there are existing benchmarks that use long double which other targets define as double and for which they generate MUCH less code size in comparison to RISC-V because of all the added long double emulation code that is pulled in. So it is convenient to me to provide an option that allows the user to rebuild his runtime and benchmark with -mlong-double-64 and see that RISC-V with the C extension isn't as poor as the benchmark might first lead them to believe.

So, is the consensus that I should only support this option out-of-tree and the community would rather not be burdened with it?

[kito-cheng]

I could imagine that using 128-bit precision is not meaningful in some embedded environments, and it could save code size on the library side, as well as some data size. So, generally, I am OK with adding a standard build attribute for that.

The only problem is we need a volunteer to prepare a psABI PR and implement that in the toolchain. I'm not interested in dealing with it, but I'm happy to review the PR and patches for the GNU toolchain, including newlib patches.

If I should us a non-standard tag, is there a policy for allocating a specific number?

PR with toolchain PoC