trunc: Use an assembly implementation on i586

[tgross35]

The trunc implementation uses integer operations so currently works
fine on i586. However, we already have the other three easy operations
based on frndint, so add trunc and complete the set.

ci: skip-extensive

[tgross35]

Based on #1142 to avoid conflicts.

[quaternic]

I don't think we should have this just for the sake of consistency. It has strictly worse performance.

[tgross35]

I don't think we should have this just for the sake of consistency. It has strictly worse performance.

What makes this slow - is frndint that much slower than soft ops? Looking at https://rust.godbolt.org/z/s6GjGsf6E I have no idea whether the latency of 100 is correct or just a worst case estimate since I can't find it cited anywhere.

Any idea why LLVM inserts the wait and why eax gets pushed? Thought that should be caller-saved.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[quaternic]

What makes this slow - is frndint that much slower than soft ops? Looking at https://rust.godbolt.org/z/s6GjGsf6E I have no idea whether the latency of 100 is correct or just a worst case estimate since I can't find it cited anywhere.

I'll admit I only tested by comparing against the x86-64 implementation. The 32-bit code does look more complex.

Measuring frndint latency (on https://en.wikipedia.org/wiki/Nehalem_(microarchitecture)):

• |x| in [0, 2^63) -> ~21 cycles
• |x| in [2^63, Inf) -> ~40 cycles
• Inf -> ~230 cycles
• NaN -> ~250 cycles

Looks like Agner Fog does provide measurements for x87 instructions too, see 4. Instruction tables in:
https://www.agner.org/optimize/#manuals

For Nehalem the listed latency for frndint is 22, so I'll assume the measurements don't consider potential input dependence, but AMD seems to have had a faster implementation since 2011. Intel does not.