https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127205
Tamar Christina <tnfchris at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tnfchris at gcc dot gnu.org
--- Comment #8 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #6)
> For the pair-fusion case it seems to me that IVOPTs should model that
> somehow (like it attempts to model autoinc).
Maybe, but the condition that make pair fusion possible are already
encoded in the existing address costing so this may be pre-mature.
>
> The author of the series claimed that the number of IVs (aka n_cands) is
> already taken into account elsewhere. The series definitely removed
> double-accounting in the register pressure cost estimate function. The main
> goal (which is achieved IMO) is to make the costing less GIGO, it now makes
> "sense", even though we of course still add and compare apples and oranges.
>
> If selecting more IVs results in cheaper use + update cost then that is
> good. Are you sure the costs are accurate on arm? (besides the missed pair
> fusion modeling?)
They're not, and it's part of what I have a team member looking into.
The AArch64 costs have (and have always had as far as I can tell):
0, /* pre_modify */
0, /* post_modify */
0, /* post_modify_ld3_st3 */
0, /* post_modify_ld4_st4 */
0, /* register_offset */
0, /* register_sextend */
0, /* register_zextend */
0 /* imm_offset */
Which is sort of true for scalar operations, since the complicated addressing
modes are "free" in terms of latency. However latency is not the full story
as for instance a register addressing mode prevents load pairs as the above
because the base changes in that case.
Similarly for vector loads a register addressing may not be free since they
are already complicated instructions and an additional register needs another
decode slot (and there are additional constraints here).
So the costs should model imm_offset as cheaper than register_* cases, however
in the past this caused IVopts to do the wrong this. Due to all the costing
fixes
around IVopts I've asked someone to re-evaluate the values.
