On 5/22/25 6:12 AM, Robin Dapp wrote:
AFAICT the main difference to standard mode switching is that we
(ab)use it to set the rounding mode to the value it had initially,
either at function entry or after a call. That's different to
regular mode switching which assumes "static" rounding modes for
different instructions.
Standard could e.g. be:
- insn1 demands frm1
- call1 demands frm4
- call2 demands frm5
Whereas we have:
- insn1 demands frm1
- call1 demands "frm at the start of the function"
- call2 demands "frm after call1 that could have called fesetround"
Weird, call2 can demand the frm as it existed after call1?!? I'm
going to try not to cry and return to my bubble :-)
Maybe demand was not really accurate. It's rather that we want call2 to
operate with the global rounding mode that call1 might have changed.
So the demand is not a specific rounding mode but rather the global one.
Right, but I don't think that changes how braindamaged I think this is
aspect of the ABI is :-) But at least I have a better sense of what
we're up against here.
Anyway, I think Vineet's patches improve on what we have right now. I'd
still like to understand if this "abuse" of mode switching gets globally
better results than a very simple approach like above. If the other
(non mode-switching) LCMs cannot really optimize FRM reads and writes
the simple approach could indeed be worse.
My worry with the standard LCM bits is they're likely going to punt when
they see a hard register and I think global optimization of copies may
not be great. I know I went through a regression eons ago that I traced
down to not having an RTL copy propagator which could handle partial
redundancies well.
jeff
