]> git.ipfire.org Git - thirdparty/gcc.git/commit
Zen5 tuning part 2: disable gather and scatter
authorJan Hubicka <jh@suse.cz>
Tue, 3 Sep 2024 13:07:41 +0000 (15:07 +0200)
committerJan Hubicka <jh@suse.cz>
Tue, 3 Sep 2024 13:07:41 +0000 (15:07 +0200)
commitd82edbe92eed53a479736fcbbe6d54d0fb42daa4
tree6d79d1df5e7f7b94127c67f895935bc2d36fb776
parent2f1689ea8e631ebb4ff3720d56ef0362f5898ff6
Zen5 tuning part 2: disable gather and scatter

We disable gathers for zen4.  It seems that gather has improved a bit compared
to zen4 and Zen5 optimization manual suggests "Avoid GATHER instructions when
the indices are known ahead of time. Vector loads followed by shuffles result
in a higher load bandwidth." however the situation seems to be more
complicated.

gather is 5-10% loss on parest benchmark as well as 30% loss on sparse dot
products in TSVC. Curiously enough breaking these out into microbenchmark
reversed the situation and it turns out that the performance depends on
how indices are distributed.  gather is loss if indices are sequential,
neutral if they are random and win for some strides (4, 8).

This seems to be similar to earlier zens, so I think (especially for
backporting znver5 support) that it makes sense to be conistent and disable
gather unless we work out a good heuristics on when to use it. Since we
typically do not know the indices in advance, I don't see how that can be done.

I opened PR116582 with some examples of wins and loses

gcc/ChangeLog:

* config/i386/x86-tune.def (X86_TUNE_USE_GATHER_2PARTS): Disable for
ZNVER5.
(X86_TUNE_USE_SCATTER_2PARTS): Disable for ZNVER5.
(X86_TUNE_USE_GATHER_4PARTS): Disable for ZNVER5.
(X86_TUNE_USE_SCATTER_4PARTS): Disable for ZNVER5.
(X86_TUNE_USE_GATHER_8PARTS): Disable for ZNVER5.
(X86_TUNE_USE_SCATTER_8PARTS): Disable for ZNVER5.
gcc/config/i386/x86-tune.def