https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121095
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|enhancement |normal
Summary|Possibly unnecessary PRE |[15/16 Regression] Possibly
|pass on aarch64 for fpmr |unnecessary PRE pass on
| |aarch64 for fpmr
Target Milestone|--- |15.2
Keywords| |memory-hog
--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to lucier from comment #2)
> My take, without having any serious knowledge of what's going on, is:
>
> If a C function doesn't involve (set, read, manipulate, ...) FP8 values or
> the fpmr register in any way, then this PRE pass shouldn't be run, because
> this PRE pass only deals with the fpmr register, and I don't see how any
> relevant code can be affected by, or can affect, the fpmr register if no FP8
> manipulations are involved in a routine.
>
> And I suggest that this should be true even if the architecture supports FP8
> arithmetic in general.
>
> I am ignorant of the details of what's going on here, so my expectation may
> very well be incorrect.
I have not looked into this far enough to say if this is possible or not. But
the first step is disable it if the arch does not support FP8 in the first
place. The next step is to look to see if it is possible to see if FPMR is ever
used/alive or not.
Note the simple patch should take care of over 90% of the cases that people
will run into; it is only for future architectures where this could come into
play.
I might take a look at the TARGET_FP8 case but not this week and most likely
not for GCC 16 either; it is definitely less important at that point.
