Add core.math.toPrec intrinsics

[ibuclaw]

Rebase of #7219.

Requires dlang/druntime#2864.

[dlang-bot]

Thanks for your pull request, @ibuclaw!

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#10654"

[thewilsonator]

Dependant druntime PR merged.

[ibuclaw]

Added back-end support for precision truncating/extending, based off CastExp. Let's see if it fixes the testsuite agrees with it...

[thewilsonator]

Please also see #10656 which is a much better way to do intrinsics.

[ibuclaw]

Apparently SIMD is broken, which means I must have messed up the intrinsic name array somehow...

[ibuclaw]

Apparently SIMD is broken, which means I must have messed up the intrinsic name array somehow...

Fixed by moving OPtoPrec to the bottom of the OPER enum... which seems to suggest there's something fishing going on in the dmd backend (bad relative comparison somewhere?).

[ibuclaw]

@thewilsonator - I'd prefer to give this a quick test/port on gdc (ppc64 more specifically) before committing, when/if this pull ever goes green.

[thewilsonator]

Don't worry I won't pull this until at least #10654 (comment) is addressed ;)

[ibuclaw]

OK, it works perfect with GDC. :-P

[ibuclaw]

The azure failures likely down to casting from longdouble (soft 80-bit) to real (native 64-bit). There's practically zero need for toPrec!real to do anything really, I'm not even sure returning a new RealExp even makes sense.

[ibuclaw]

@thewilsonator - I think we're all green now.

[ibuclaw]

@don-clugston-sociomantic - does this sufficiently satisfy https://issues.dlang.org/show_bug.cgi?id=9937 ?

Example usage of it, where double precision is forced at specific checkpoints in the CTFE code is found here.
https://github.com/dlang/druntime/blob/f7d2bbd2952ec644bf0ce7855195dc39760205aa/src/core/internal/convert.d#L74-L105

[don-clugston-sociomantic]

Finally! This is long overdue!
The corresponding druntime PR says it "forces rounding of the argument f to the precision of the specified floating point type T"

It does not say which form of rounding is used. Since the purpose of this to eradicate machine-specific bits, the compiler can do it however it likes,
Suggested wording:
"The rounding is inevitably machine-dependent, but will be done in a way to maximize accuracy. In most cases round-to-nearest will be used."

Not sure if 'machine-dependent' is the right word, but it's more than just CPU-dependent, it may depend on the OS as well.

[ibuclaw]

It does not say which form of rounding is used. Since the purpose of this to eradicate machine-specific bits, the compiler can do it however it likes,

At runtime, the codegen is indistinguishable from a cast().

During CTFE, dmd stores the value as the requested type, which I imagine would be just loading it in the appropriate register. GDC and probably LDC will truncate or extend the representation so that it fits the target type.

Suggested wording:
"The rounding is inevitably machine-dependent, but will be done in a way to maximize accuracy. In most cases round-to-nearest will be used."

Not sure if 'machine-dependent' is the right word, but it's more than just CPU-dependent, it may depend on the OS as well.

It would depend on the default rounding mode for the type. Looking at the list of possible formats, there's only one that instead rounds to zero.

If the PR hasn't been merged, I can bundle in the comment in the second toPrec PR I made.

[thewilsonator]

Is this good to go?

[don-clugston-sociomantic]

Looks good to me.