https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127467
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu.org
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to ptomsich from comment #2)
> (In reply to Richard Biener from comment #1)
> > But sure, taking a not profitable SLP subgraph and simply re-assigning
> > vector types would be a more proper implementation of mode iteration.
> > I think I've seen folks working on something like that?
>
> We have something adjacent, though it re-assigns nothing about the mode. On a
> cost-rejected BB-SLP subgraph we retry each instance on its own: cross-shared
> children are replaced with private copies (constants and externals are
> cloned,
> interior nodes are demoted to externals of their scalar results), the
> instance
> is then re-analyzed and re-costed alone, and accepted as its own subgraph if
> it
> is individually profitable. The motivation was the same all-or-nothing
> verdict
> you describe (vect_bb_partition_graph fuses instances that merely share
> scalar stmts, so one unprofitable instance discards its profitable
> neighbours).
If you discard some entries you have to re-evaluate coverage & live lanes
and cost those. "merely sharing scalar stmts" means you do not have to
worry about that and that's the reason to fuse.
> We had been targeting AArch64, so didn't even consider looking for motivating
> cases on x86-64...
>
> On the attached testcase with
> -O3 -march=x86-64-v4 -mtune-ctrl=avx512_avoid_vec_perm
> -mprefer-vector-width=512
> our WIP tree recovers most of what the 256-bit path finds:
> unpatched, 512: 1 loop + 1 basic block part 376 insns
> patched, 512: 1 loop + 13 basic block parts 356 insns
> either, 256: 1 loop + 14 basic block parts 194 insns
>
> -fdump-tree-slp-details shows the 12 retires, which is exactly the 12
> additional parts. At -mprefer-vector-width=256 patched and unpatched emit
> byte-identical assembly, so this only acts on the path that is currently
> missed.
>
> We have some more work to do on this, but I'll ping this ticket once
> something
> goes onto the list.
Thanks. I do think the BB mode iteration is quite pointless as it isn't
effective in most cases, for this very reason. So it should be reworked.
