[Bug libgcc/108279] Improved speed for float128 routines

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279

--- Comment #6 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Michael_S from comment #5)
> Hi Thomas
> Are you in or out?

Depends a bit on what exactly you want to do, and if there is
a chance that what you want to do will be incorporated into gcc.

If you want to replace the soft-float routines, you will have to
replace them with the full functionality.

And there will have to be a decision about 32-bit targets.

> If you are still in, I can use your help on several issues.
> 
> 1. Torture. 
> See if Invalid Operand exception raised properly now. Also if there are
> still remaining problems with NaN.

I've putyour addition/subtraction routines in as a replacement
an am running a regression test.  We'll see when that finishes.

> 2. Run my correction tests on as many non-AMD64 targets as you can.
> Preferably, with 100,000,000 iterations, but on weaker HW 10,000,000 will do.

This will take some time.

> 3. Run my speed tests (tests/matmulq/mm_speed_ma) on more diverse set of
> AMD64 computers than I did.
> Of special interest are
> - AMD Zen3 on Linux running on bare metal
> - Intel Skylake, SkylakeX, Tiger/Rocket Lake and Alder Lake on Linux running
> on bare metal
> I realize that doing speed tests is not nearly as simple as correctness
> tests.
> We need non-busy (preferably almost idle) machines that have stable CPU
> clock rate. It's not easy to find machines like that nowadays. But, may be,
> you can find at least some from the list.

I currenty have no access to that sort of hardware (I'm just a volunteer,
and my home box is Zen-1).

> 4. Run my speed tests on as many non-obsolete ARM64 computers as you can
> find.
> Well, probably a wishful thinking on my part.
> 
> 
> Also off topic but of interest: postprocessed source of matmul_r16.c

Where should I send that to?