Fix signature of memory_f80 intrinsics #729
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes a longstanding issue where the 80-bit floats would not be passed correctly to the
memory_f80functions.After #723 the semantics are compiled as
x86_64-none-elfwith-ffreestanding(fully OS independent) and-mlong-double-80to support 80-bit floats in the generated IR. The idea is that the instruction semantics themselves are 'pure' LLVM IR that we can freely retarget for our purposes without having to worry about ABI changes. This works because theStatestructure is packed and we useuintXX_tin the helper signatures.The
native_float80_tappears to have been designed to convert betweenstruct float80_t { uint8_t data[10]; }and whatever is the widestlong doubleavailable on the target platform. Unfortunately this type was used in the intrinsics:This causes an ABI break of sorts, because the intrinsics might be targeting Windows (MSVC) which does not support
long double. We should instead passfloat80_t, which has a known layout across all target triples and the intrinsic implementation for that platform is responsible for handling conversions (usingnative_float80_tif they desire).In practice this likely would not matter much, since the higher 2 bytes are for additional precision and they do not represent any 'meaningful' bits of the float. If your platform does not support 80-bit floats it's just not the same as native x87 operations, but with this change you can (in theory) use a softfloat implementation to get perfect semantics.