]> gcc.gnu.org Git - gcc.git/commit
Enable 512 bit vector for zen4
authorJan Hubicka <jh@suse.cz>
Tue, 7 Feb 2023 04:23:00 +0000 (05:23 +0100)
committerJan Hubicka <jh@suse.cz>
Tue, 14 Mar 2023 08:16:45 +0000 (09:16 +0100)
commit2166a87cefde15ec7798914095d9a61566e7fccd
treead0fa80b783f6adcf2c5c63c4abf2814cec42c37
parent225cd987351d3558612107bc95c1f9c033fde5f1
Enable 512 bit vector for zen4

While internally 512 registers are splits into two 256 halves, 512 bit vectors
reduces number of instructions to retire and has chance to improve paralelism.
There are few tsvc benchmarks that improves significantly:

           runtime
benchmark  256bit  512bit
s2275      48.57   20.67    -58%
s311       32.29   16.06    -50%
s312       32.30   16.07    -50%
vsumr      32.30   16.07    -50%
s314       10.77   5.42     -50%
s313       21.52   10.85    -50%
vdotr      43.05   21.69    -50%
s316       10.80   5.64     -48%
s235       61.72   33.91    -45%
s161       15.91   9.95     -38%
s3251      32.13   20.31    -36%

And there are no benchmarks with off-noise regression.  The basic matrix
multiplication loop improves by 32%.  It is also expected that 512 bit
vectors are more power effecient (I can't masure that).

The down side is that loops with low trip counts may get slower when the
unvectorized prologue and epilogue is hit more often.  With SPECfp this
problem happens with x264 (12% regression) and bwaves (6% regression)
and this is tracked in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108410
and will need more work on vectorizer to support masked epilogues.

After some additional testing it seems that using 512 bit vectors by
default is now overall better choice.

Bootstrapped/regtested x86_64-linux. Plan to commit it tomorrow.

* config/i386/x86-tune.def (X86_TUNE_AVX256_OPTIMAL): Turn off
for znver4.

(cherry picked from commit a7502c4a614238ac3f80271886b217b156bdf923)
gcc/config/i386/x86-tune.def
This page took 0.061814 seconds and 5 git commands to generate.