https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121095
Segher Boessenkool <segher at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |segher at gcc dot gnu.org
--- Comment #8 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Hi!
(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.
Yup. Andrew's patch does pretty much this, right?
> 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.
>
> This PRE pass wasn't run on this example function because more than 128MB of
> memory would have been needed, but when building the Gambit Scheme system
> there are many relatively large routines where this PRE pass is run.
The hardreg PRE pass makes a lot of garbage, just because of how it works
(nested loops, a loop per reg, it could be coded a bit smarter).
> In another large file where this PRE pass was run, the dump file contained:
>
> PRE GCSE of ___H___num, 31567 basic blocks, 2524104 bytes needed, 0 substs,
> 0 insns created
>
> Does "0 substs, 0 insns created" mean that running the pass had no effect on
> the code?
Pretty much, yes.
