On Tue, 30 Jul 2024, Alexander Monakov wrote:
>
> On Tue, 30 Jul 2024, Richard Biener wrote:
>
> > > Oh, and please add a small comment why we don't use XFmode here.
> >
> > Will do.
> >
> > /* Do not enable XFmode, there is padding in it and it suffers
> > from normalization upon load like SFmode and DFmode when
> > not using SSE. */
>
> Is it really true? I have no evidence of FLDT performing normalization
> (as mentioned in PR 114659, if it did, there would be no way to spill/reload
> x87 registers).
What mangling fld performs depends on the contents of the FP control
word which is awkward. IIRC there's at least a bugreport that it
turns sNaN into a qNaN, it seems I was wrong about denormals
(when DM is not masked). And yes, IIRC x87 instability is also
related to spills (IIRC we spill in the actual mode of the reg, not in
XFmode), but -fexcess-precision=standard should hopefully avoid that.
It's also not clear whether all implementations conformed to the
specs wrt extended-precision format loads.
> (the padding is not part of the 80-bit mode precision of XFmode, right?)
As Jakub said the padding is already dealt with in the caller
though I only added that there for convenience since padding is
problematic in general.
If you think XFmode is safe to transfer 10 bytes we could enable it,
I guess I'll amend the docs to be clear:
"Define this to return false if the mode @var{mode} cannot be used
for memory copying. The default is to assume modes with the same
precision as size are fine to be used."
this might suggest transfering GET_MODE_PRECISION bits is intended
but it might want to say GET_MODE_SIZE units explicitly so the
default makes sense.
Richard.
