port longdouble.* to D to allow building dmd with LDC on Windows

[rainers]

LDC for MSVC uses 64-bit reals similar to the C runtime, so using the longdouble struct is necessary to compile to 80-bit reals (already used when building the backend with VC).

Building the frontend with LDC (v1.6.0-beta1) has noticable effect on build times, for example the druntime/phobos unittests build about 20% faster (64-bit version with the backend built with VC for both).

Slightly OT: while building the debug version of the dmd frontend with LDC takes almost twice as much time as with DMD, the release is faster with LDC than DMD (1min05 vs. 1min34).

[dlang-bot]

Thanks for your pull request, @rainers!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + dmd#7339"

[kinke]

Interesting work; it also paves the way for LDC on MSVC hosts to use 80-bit compile-time reals, which would be required for proper cross-compilation to other x86(_64) targets with 80-bit reals (although probably more work is needed to support all CTFE builtins).

the release is faster with LDC than DMD (1min05 vs. 1min34).

Also very interesting.

[ibuclaw]

I'd hate to say told you so, when I argued why aliasing longdouble to real is an implementation regression.

[rainers]

I'd hate to say told you so, when I argued why aliasing longdouble to real is an implementation regression.

I don't remember all the details ;-) Would you consider this PR a step in the right direction? It removes explicit usage of real in the front end and allows implementing it with higher precision than what the host compiler uses for real.

[ibuclaw]

I don't remember all the details ;-)

#5237 (comment) :-)

Would you consider this PR a step in the right direction?

I am doing something similar (or the same thing) in gdc port D-Programming-GDC/gdc#550

Implementation here:
https://github.com/ibuclaw/GDC/blob/c9fa6221791f11fae4aec11eedc441d1f86981f8/gcc/d/ddmd/root/ctfloat.d#L21

[rainers]

#5237 (comment) :-)

Now I remember :)

Implementation here:

Yeah, this looks very similar. Casts to float/double seems to use integers, though, but you might not need it in GDC? It's only used by e2ir.d and iasm.d in dmd.

[ibuclaw]

Casts to float/double seems to use integers, though, but you might not need it in GDC?

Correct, there's no floating point types used in gdc, and most of gcc too.

[Temtaime]

@rainers Seems to be abandoned ? Then better close.

[ibuclaw]

Native floating point should be killed and banned from the frontend compiler internals.

[rainers]

Rebased. Unfortunately, released LDC versions crash on the current dmd source (as all dmd versions prior to 2.078).

[rainers]

Verified with LDC master.

[Temtaime]

Tests're ok
@ibuclaw

[Temtaime]

No merge so far ?
As usual, an abandoned pr.

[WalterBright]

It bothers me that we have real_t, longdouble, and targ_ldouble, all of which purported to be solutions to this problem. I've seen PRs for years switching around between these three. Even this PR uses all three. I don't want to pull this until there's a coherent description of what each of these is and when they should be used. Currently, I have no idea.

[dnadlinger]

real_t is the type used throughout the frontend to represent real values during compilation. Use this.

longdouble is the name of Rainer's "universal" (x86) 80 bit real implementation, which falls back on x87 ASM where required (MSVC/Win64). It shouldn't be used directly. We could give it a name like x87FloatImpl or something, if that helps.

targ_ldouble is the type used in the backend, similar to all the other targ_* typedefs for host types. Like real_t in the frontend, it should be used whenever target reals are handled.

---

This PR needs to use all three, as it modifies the definitions of real_t and targ_ldouble such that a compiler built with is(real == double) – LDC targeting Win64 – can target x87 reals.

[rainers]

Thanks @klickverbot for clarifying. Should I add something similar as a comment to longdouble.*?

I have rebased and retested with LDC 1.7.0, no issues. Should we add a test to the Appveyor build? That could be some work, but seems reasonable to replace dmd as the host compiler when building through VS.

BTW: with longdouble implemented in D we could get rid of the ASM file and use inline assembly on all targets instead.

[WalterBright]

Yes, thanks for the clarification. This explanation needs to be where the aliases are in the code.

[wilzbach]

I have rebased and retested with LDC 1.7.0, no issues. Should we add a test to the Appveyor build? That could be some work, but seems reasonable to replace dmd as the host compiler when building through VS.

Yeah that would be really cool. Especially given that ideally the "official" release archives/binaries/installer should be built with LDC for better performance too.