From: Jeff Law <jeffreyalaw@gmail.com>
To: Maxim Blinov <maxim.a.blinov@gmail.com>
Cc: gcc@gcc.gnu.org, kito.cheng@gmail.com, juzhe.zhong@rivai.ai
Subject: Re: Lots of FAILs in gcc.target/riscv/rvv/autovec/*
Date: Wed, 8 Nov 2023 07:31:56 -0700 [thread overview]
Message-ID: <5144715c-08e7-4f80-b6dd-c4f126050538@gmail.com> (raw)
In-Reply-To: <CAHXVFWkODGMYFhKMMotyUvXLYnoOTAfUSde=6Yu2Lgzg1MTBuA@mail.gmail.com>
On 11/7/23 21:31, Maxim Blinov wrote:
> I see, thanks for clarifying, that makes sense.
>
> In that case, what about doing the inverse? I mean, are there unique
> patches in the vendor branch, and would it be useful to try to
> upstream them into master? My motivation is to get the best
> autovectorized code for RISC-V.
There should be nothing on the vendor branch that is not already on the
trunk. If there is, something has gone horribly wrong.
The process we've used over there is pretty simple. Start with the
gcc-13 branch, then cherry pick risc-v backend & testsuite changes from
the trunk as well as limited target independent changes (primarily those
which the risc-v backend depends on, or which we know/expect are
important for risc-v for one reason or another).
>
> I had a go at building the TSVC benchmark (in the llvm-test-suite[1]
> repository) both with the master and vendor branch gcc, and noticed
> that the vendor branch gcc generally beats master in generating more
> vector instructions.
>
> If I simply count the number of instances of each vector instruction,
> the average across all 36 test cases of vendor vs master gcc features
> the following most prominent differences:
>
> - vmv.x.s: 48 vs 0 (+ 48)
> - vle32.v: 150 vs 50 (+ 100)
> - vrgather.vv: 61 vs 0 (+ 61)
> - vslidedown.vi: 61 vs 0 (+ 61)
> - vse32.v: 472 vs 213 (+ 459)
> - vmsgtu.vi: 30 vs 0 (+ 30)
> - vadd.vi: 80 vs 30 (+ 50)
> - vlm.v: 18 vs 0 (+ 18)
> - vsm.v: 16 vs 0 (+ 16)
> - vmv4r.v: 21 vs 7 (+ 14)
>
> (For reference, the benchmarks are all between 20k-30k in code size.
> Built with `-march=rv64imafdcv -O3`.)
>
> Ofcourse that doesn't say anything about performance, but would it be
> possible/fair to say that the vendor branch may still be better than
> master for generating vectorized code for RISC-V?
>
> What's interesting is that there's very little "regression" - I saw
> only very few cases where the vendor branch removed a vector
> instruction as compared to master gcc (the most often removed
> instruction by the vendor branch, as compared to master, is
> vsetvl/vsetvli.)
If the vendor branch is generating better code than the trunk then
that's an indication that target independent changes on the trunk from
the gcc-14 development cycle need some work ;)
Just comparing the static number of instructions isn't useful at all
IMHO. Now you can get dynamic instructions from various QEMU plugins at
which point the data becomes much more interesting -- though you have to
be careful interpreting that as well.
Jeff
prev parent reply other threads:[~2023-11-08 14:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-07 12:50 Maxim Blinov
2023-11-07 15:53 ` Jeff Law
2023-11-08 4:31 ` Maxim Blinov
2023-11-08 4:40 ` juzhe.zhong
2023-11-08 4:44 ` Andrew Pinski
2023-11-08 14:31 ` Jeff Law [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5144715c-08e7-4f80-b6dd-c4f126050538@gmail.com \
--to=jeffreyalaw@gmail.com \
--cc=gcc@gcc.gnu.org \
--cc=juzhe.zhong@rivai.ai \
--cc=kito.cheng@gmail.com \
--cc=maxim.a.blinov@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).