https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109610
Kewen Lin <linkw at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |linkw at gcc dot gnu.org
--- Comment #12 from Kewen Lin <linkw at gcc dot gnu.org> ---
By looking into this failure, I found something tricky related to the cost
adjustment for this kind of destination pseudo:
/* If this insn loads a parameter from its stack slot, then it
represents a savings, rather than a cost, if the parameter is
stored in memory. Record this fact.
Similarly if we're loading other constants from memory (constant
pool, TOC references, small data areas, etc) and this is the only
assignment to the destination pseudo.
Hongtao already has one fix for this regression (thanks!), but IMHO this tricky
thing might affect any future adjustment on this particular cost, so I posted
my findings here:
This above adjustment can happen on the destination pseudo of a load insn with
one equiv note, but the equiv note can be created later by update_equiv_regs
during ira (it's the case this failure here), it means this memory cost
reduction isn't considered in the first pass of best class determination, whose
resulted pref used for the second pass of best class determination can be not
good enough (not the best). In the 2nd pass, when scanning insn 13
r119:V2DF=r117:V2DF, cost calculation would respect the pref VSX_REGS for r117,
penalizes alternative whose operand 1 have operand class NO_REGS (r117), but at
this time the pref isn't the best as the pref VSX_REGS determination doesn't
consider the memory cost reduction, so I think we should give it a chance to
re-consider NO_REGS and not to penalize that corresponding alternative. Not
sure this kind of re-consideration (forgiving if it's NO_REGS) is worthy or
not, actually it's independent of this regression issue, maybe I can give it a
shot with some SPEC2017 runs.
