Lots of FAILs in gcc.target/riscv/rvv/autovec/*
Hi all, I can see about 500 failing tests on the vendors/riscv/gcc-13-with-riscv-opts, a mostly-full list at the bottom of this email. It's mostly test cases scraping for vector instructions. However, these tests all pass on master. Presumably the vendor branch failures can all be fixed by cherry picking the right patches from master, but figuring out which ones is probably going to be a slog, so I wanted to ask if there's any desire/point in doing so? Would it be better to just wait until these are automagically fixed by a future rebase? BR, Maxim --- Unique files that trigger failures in vendor branch, but not in master: gcc.target/riscv/rvv/autovec/cond/cond_unary-1.c gcc.target/riscv/rvv/autovec/cond/cond_unary-2.c gcc.target/riscv/rvv/autovec/cond/cond_unary-3.c gcc.target/riscv/rvv/autovec/cond/cond_unary-4.c gcc.target/riscv/rvv/autovec/cond/cond_unary-5.c gcc.target/riscv/rvv/autovec/cond/cond_unary-6.c gcc.target/riscv/rvv/autovec/cond/cond_unary-7.c gcc.target/riscv/rvv/autovec/cond/cond_unary-8.c gcc.target/riscv/rvv/autovec/gather-scatter/strided_load-2.c gcc.target/riscv/rvv/autovec/pr111751.c gcc.target/riscv/rvv/autovec/slp-mask-1.c gcc.target/riscv/rvv/autovec/struct/mask_struct_load-1.c gcc.target/riscv/rvv/autovec/struct/mask_struct_load-2.c gcc.target/riscv/rvv/autovec/struct/mask_struct_load-3.c gcc.target/riscv/rvv/autovec/struct/mask_struct_load-4.c gcc.target/riscv/rvv/autovec/struct/mask_struct_load-5.c gcc.target/riscv/rvv/autovec/struct/mask_struct_load-6.c gcc.target/riscv/rvv/autovec/struct/mask_struct_load-7.c gcc.target/riscv/rvv/autovec/struct/mask_struct_store-1.c gcc.target/riscv/rvv/autovec/struct/mask_struct_store-2.c gcc.target/riscv/rvv/autovec/struct/mask_struct_store-3.c gcc.target/riscv/rvv/autovec/struct/mask_struct_store-4.c gcc.target/riscv/rvv/autovec/struct/mask_struct_store-5.c gcc.target/riscv/rvv/autovec/struct/mask_struct_store-6.c gcc.target/riscv/rvv/autovec/struct/mask_struct_store-7.c gcc.target/riscv/rvv/autovec/struct/struct_vect-10.c gcc.target/riscv/rvv/autovec/struct/struct_vect-11.c gcc.target/riscv/rvv/autovec/struct/struct_vect-12.c gcc.target/riscv/rvv/autovec/struct/struct_vect-13.c gcc.target/riscv/rvv/autovec/struct/struct_vect-14.c gcc.target/riscv/rvv/autovec/struct/struct_vect-15.c gcc.target/riscv/rvv/autovec/struct/struct_vect-16.c gcc.target/riscv/rvv/autovec/struct/struct_vect-17.c gcc.target/riscv/rvv/autovec/struct/struct_vect-18.c gcc.target/riscv/rvv/autovec/struct/struct_vect-1.c gcc.target/riscv/rvv/autovec/struct/struct_vect-2.c gcc.target/riscv/rvv/autovec/struct/struct_vect-3.c gcc.target/riscv/rvv/autovec/struct/struct_vect-4.c gcc.target/riscv/rvv/autovec/struct/struct_vect-5.c gcc.target/riscv/rvv/autovec/struct/struct_vect-6.c gcc.target/riscv/rvv/autovec/struct/struct_vect-7.c gcc.target/riscv/rvv/autovec/struct/struct_vect-8.c gcc.target/riscv/rvv/autovec/struct/struct_vect-9.c gcc.target/riscv/rvv/autovec/vls/cond_not-1.c
Re: Checks that autotools generated files were re-generated correctly
On 11/7/23 02:38, Maxim Kuvyrkov wrote: >> On Nov 6, 2023, at 21:19, Christophe Lyon >> wrote: >> >> Hi! >> >> On Mon, 6 Nov 2023 at 18:05, Martin Jambor >> wrote: >>> >>> Hello, >>> >>> I have inherited Martin Liška's buildbot script that checks that >>> all sorts of autotools generated files, mainly configure scripts, >>> were re-generated correctly when appropriate. While the checks >>> are hopefully useful, they report issues surprisingly often and >>> reporting them feels especially unproductive. >>> >>> Could such checks be added to our server side push hooks so that >>> commits introducing these breakages would get refused >>> automatically. While the check might be a bit expensive, it only >>> needs to be run on files touching the generated files and/or the >>> files these are generated from. $0.02. We should move in a direction where all server side push hooks removed. Removing the hooks allows for easy repo replication, and sharing load. Such checks should all be moved IMO into pre-commit CI, or post-commit CI. >>> Alternatively, Maxim, you seem to have an infrastructure that is >>> capable of sending email. Would you consider adding the check to >>> your buildbot instance and report issues automatically? The >>> level of totally >> >> After the discussions we had during Cauldron, I actually thought >> we should add such a bot. >> >> Initially I was thinking about adding this as a "precommit" check, >> to make sure the autogenerated files were submitted correctly, but >> I realized that the policy is actually not to send autogenerated >> files as part of the patch (thus making pre-commit check >> impracticable in such cases, unless we autogenerate those files >> after applying the patch) >> >> I understand you mean to run this as a post-commit bot, meaning we >> would continue to "accept" broken commits, but now automatically >> send a notification, asking for a prompt fix? >> >> We can probably implement that, indeed. Is that the general >> agreement? > > [CC: Siddhesh, Carlos] > > Hi Martin, > > I agree with Christophe, and we can add various source-level checks > and wrap them up as a post-commit job. The job will then send out > email reports to developers whose patches failed it. This is a great way to handle this until we have more consensus around other kinds of worfklows. > Where the current script is located? These checks would be useful > for all GNU Toolchain projects -- binutils/GDB, GCC, Glibc and, > maybe, Newlib -- so it would be useful to put it in a separate > "gnutools" repo. I think Siddhesh and Carlos are looking into > creating such a repo on gitlab? I can make any repo we want here: https://gitlab.com/gnutools -- Cheers, Carlos.
Re: Checks that autotools generated files were re-generated correctly
Hello,
On Tue, Nov 07 2023, Maxim Kuvyrkov wrote:
n>> On Nov 6, 2023, at 21:19, Christophe Lyon
wrote:
>>
>> Hi!
>>
>> On Mon, 6 Nov 2023 at 18:05, Martin Jambor wrote:
>>>
>>> Hello,
>>>
>>> I have inherited Martin Liška's buildbot script that checks that all
>>> sorts of autotools generated files, mainly configure scripts, were
>>> re-generated correctly when appropriate. While the checks are hopefully
>>> useful, they report issues surprisingly often and reporting them feels
>>> especially unproductive.
>>>
>>> Could such checks be added to our server side push hooks so that commits
>>> introducing these breakages would get refused automatically. While the
>>> check might be a bit expensive, it only needs to be run on files
>>> touching the generated files and/or the files these are generated from.
>>>
>>> Alternatively, Maxim, you seem to have an infrastructure that is capable
>>> of sending email. Would you consider adding the check to your buildbot
>>> instance and report issues automatically? The level of totally
>>
>> After the discussions we had during Cauldron, I actually thought we
>> should add such a bot.
>>
>> Initially I was thinking about adding this as a "precommit" check, to
>> make sure the autogenerated files were submitted correctly, but I
>> realized that the policy is actually not to send autogenerated files
>> as part of the patch (thus making pre-commit check impracticable in
>> such cases, unless we autogenerate those files after applying the
>> patch)
>>
>> I understand you mean to run this as a post-commit bot, meaning we
>> would continue to "accept" broken commits, but now automatically send
>> a notification, asking for a prompt fix?
My thinking was that ideally bad commits would get refused early, like
when you get your ChangeLog completely wrong, but if there are drawbacks
to that approach, a completely automated notification system would be
great too.
>>
>> We can probably implement that, indeed. Is that the general agreement?
>
> [CC: Siddhesh, Carlos]
>
> Hi Martin,
>
> I agree with Christophe, and we can add various source-level checks
> and wrap them up as a post-commit job. The job will then send out
> email reports to developers whose patches failed it.
Thanks, automating this would be a huge improvement.
>
> Where the current script is located? These checks would be useful for
> all GNU Toolchain projects -- binutils/GDB, GCC, Glibc and, maybe,
> Newlib -- so it would be useful to put it in a separate "gnutools"
> repo.
The test consists of running a python script that I'm pasting below in a
directory with a current master branch and subsequently checking that
"git diff" does not actually produce any diff (which currently does).
You need to have locally built autotools utilities of exactly the right
version. The script (written by Martin Liška) is:
-- 8< --
#!/usr/bin/env python3
import os
import subprocess
from pathlib import Path
AUTOCONF_BIN = 'autoconf-2.69'
AUTOMAKE_BIN = 'automake-1.15.1'
ACLOCAL_BIN = 'aclocal-1.15.1'
AUTOHEADER_BIN = 'autoheader-2.69'
ENV = f'AUTOCONF={AUTOCONF_BIN} ACLOCAL={ACLOCAL_BIN} AUTOMAKE={AUTOMAKE_BIN}'
config_folders = []
for root, _, files in os.walk('.'):
for file in files:
if file == 'configure':
config_folders.append(Path(root).resolve())
for folder in sorted(config_folders):
print(folder, flush=True)
os.chdir(folder)
configure_lines = open('configure.ac').read().splitlines()
if any(True for line in configure_lines if
line.startswith('AC_CONFIG_HEADERS')):
subprocess.check_output(f'{ENV} {AUTOHEADER_BIN} -f', shell=True,
encoding='utf8')
# apparently automake is somehow unstable -> skip it for gotools
if (any(True for line in configure_lines if
line.startswith('AM_INIT_AUTOMAKE'))
and not str(folder).endswith('gotools')):
subprocess.check_output(f'{ENV} {AUTOMAKE_BIN} -f',
shell=True, encoding='utf8')
subprocess.check_output(f'{ENV} {AUTOCONF_BIN} -f', shell=True,
encoding='utf8')
-- 8< --
> I think Siddhesh and Carlos are looking into creating such a repo on
> gitlab?
I guess this particular script may be even put into gcc's contrib
directory. But it can be put anywhere where it makes most sense and
suits you best.
Thanks,
Martin
Re: Checks that autotools generated files were re-generated correctly
On Tue, 7 Nov 2023 at 15:36, Martin Jambor wrote:
>
> Hello,
>
> On Tue, Nov 07 2023, Maxim Kuvyrkov wrote:
> n>> On Nov 6, 2023, at 21:19, Christophe Lyon
> wrote:
> >>
> >> Hi!
> >>
> >> On Mon, 6 Nov 2023 at 18:05, Martin Jambor wrote:
> >>>
> >>> Hello,
> >>>
> >>> I have inherited Martin Liška's buildbot script that checks that all
> >>> sorts of autotools generated files, mainly configure scripts, were
> >>> re-generated correctly when appropriate. While the checks are hopefully
> >>> useful, they report issues surprisingly often and reporting them feels
> >>> especially unproductive.
> >>>
> >>> Could such checks be added to our server side push hooks so that commits
> >>> introducing these breakages would get refused automatically. While the
> >>> check might be a bit expensive, it only needs to be run on files
> >>> touching the generated files and/or the files these are generated from.
> >>>
> >>> Alternatively, Maxim, you seem to have an infrastructure that is capable
> >>> of sending email. Would you consider adding the check to your buildbot
> >>> instance and report issues automatically? The level of totally
> >>
> >> After the discussions we had during Cauldron, I actually thought we
> >> should add such a bot.
> >>
> >> Initially I was thinking about adding this as a "precommit" check, to
> >> make sure the autogenerated files were submitted correctly, but I
> >> realized that the policy is actually not to send autogenerated files
> >> as part of the patch (thus making pre-commit check impracticable in
> >> such cases, unless we autogenerate those files after applying the
> >> patch)
> >>
> >> I understand you mean to run this as a post-commit bot, meaning we
> >> would continue to "accept" broken commits, but now automatically send
> >> a notification, asking for a prompt fix?
>
> My thinking was that ideally bad commits would get refused early, like
> when you get your ChangeLog completely wrong, but if there are drawbacks
> to that approach, a completely automated notification system would be
> great too.
>
Well, making such checks in a precommit-CI means that authors should
include regenerated files in their patch submissions, so it seems this
would imply a policy change (not impossible, but will likely take some
time to get consensus?)
> >>
> >> We can probably implement that, indeed. Is that the general agreement?
> >
> > [CC: Siddhesh, Carlos]
> >
> > Hi Martin,
> >
> > I agree with Christophe, and we can add various source-level checks
> > and wrap them up as a post-commit job. The job will then send out
> > email reports to developers whose patches failed it.
>
> Thanks, automating this would be a huge improvement.
>
> >
> > Where the current script is located? These checks would be useful for
> > all GNU Toolchain projects -- binutils/GDB, GCC, Glibc and, maybe,
> > Newlib -- so it would be useful to put it in a separate "gnutools"
> > repo.
>
> The test consists of running a python script that I'm pasting below in a
> directory with a current master branch and subsequently checking that
> "git diff" does not actually produce any diff (which currently does).
Great, I was thinking about writing something like that :-)
> You need to have locally built autotools utilities of exactly the right
> version. The script (written by Martin Liška) is:
>
> -- 8< --
> #!/usr/bin/env python3
>
> import os
> import subprocess
> from pathlib import Path
>
> AUTOCONF_BIN = 'autoconf-2.69'
> AUTOMAKE_BIN = 'automake-1.15.1'
> ACLOCAL_BIN = 'aclocal-1.15.1'
> AUTOHEADER_BIN = 'autoheader-2.69'
>
> ENV = f'AUTOCONF={AUTOCONF_BIN} ACLOCAL={ACLOCAL_BIN} AUTOMAKE={AUTOMAKE_BIN}'
>
> config_folders = []
>
> for root, _, files in os.walk('.'):
> for file in files:
> if file == 'configure':
> config_folders.append(Path(root).resolve())
>
> for folder in sorted(config_folders):
> print(folder, flush=True)
> os.chdir(folder)
> configure_lines = open('configure.ac').read().splitlines()
> if any(True for line in configure_lines if
> line.startswith('AC_CONFIG_HEADERS')):
> subprocess.check_output(f'{ENV} {AUTOHEADER_BIN} -f', shell=True,
> encoding='utf8')
> # apparently automake is somehow unstable -> skip it for gotools
> if (any(True for line in configure_lines if
> line.startswith('AM_INIT_AUTOMAKE'))
> and not str(folder).endswith('gotools')):
> subprocess.check_output(f'{ENV} {AUTOMAKE_BIN} -f',
> shell=True, encoding='utf8')
> subprocess.check_output(f'{ENV} {AUTOCONF_BIN} -f', shell=True,
> encoding='utf8')
>
> -- 8< --
Nice, thanks for sharing.
>
> > I think Siddhesh and Carlos are looking into creating such a repo on
> > gitlab?
>
> I guess this particular script may be even put into gcc's contrib
> directory. But it can be put anywhere where it makes most sen
Re: Lots of FAILs in gcc.target/riscv/rvv/autovec/*
On 11/7/23 05:50, Maxim Blinov wrote: Hi all, I can see about 500 failing tests on the vendors/riscv/gcc-13-with-riscv-opts, a mostly-full list at the bottom of this email. It's mostly test cases scraping for vector instructions. Correct. There are generic vectorizer changes that would need to be ported over to that branch to make those tests pass. I looked at this a few times and ultimately gave up in the rats nest of inter-dependent patches in the vectorizer. Given the lifetime of that branch is likely nearing its end, I don't think there's much value left in trying to port those changes over. Any such effort would likely be better spent nailing down issues on the trunk. jeff
Article suggestion (note for admin)
Hi GCC Team, I wanted to follow up once more regarding the latest STD statistics in the US. As I mentioned previously, I believe the data could be a useful resource for your audience. You can find the full report here: https://backgroundchecks.org/which-states-have-the-most-stds.html If you're the person who updates your page, would you be open to including our updated report? Let me know your thoughts, Dwayne Jacobs Director of Public Outreach BackgroundChecks.org d.jac...@backgroundchecksmailing.org If you don't think this resource would be helpful, just reply with “unsubscribe."
Re: Article suggestion (note for admin)
We have many STDs. stdio stdlib libstdc++ On Tue, Nov 7, 2023 at 7:57 AM Dwayne Jacobs < d.jac...@backgroundchecksmailing.org> wrote: > Hi GCC Team, > > I wanted to follow up once more regarding the latest STD statistics in the > US. > > As I mentioned previously, I believe the data could be a useful resource > for your audience. > > You can find the full report here: > https://backgroundchecks.org/which-states-have-the-most-stds.html > > If you're the person who updates your page, would you be open to including > our updated report? > > Let me know your thoughts, > > Dwayne Jacobs > Director of Public Outreach > BackgroundChecks.org > d.jac...@backgroundchecksmailing.org > > > If you don't think this resource would be helpful, just reply with > “unsubscribe." >
Re: Checks that autotools generated files were re-generated correctly
Martin Jambor writes:
> [...] I have inherited Martin Liška's buildbot script that checks
> that all sorts of autotools generated files, mainly configure scripts,
> were re-generated correctly when appropriate. [...]
The gccadmin account on sourceware already does some daily routine git
commits ("Daily bump."). You could decide to delegate regeneration of
the configury to the same service. It could run on a scheduled basis
rather than the commit hook, if people are angsty about that.
It would use designated master auto* tool versions. None of the
developers would have to struggle keeping them matched: just commit the
inputs. Or if they commit regenerated versions but with an oddball
auto* version, the sourceware bot could fix that later.
- FChE
Re: Lots of FAILs in gcc.target/riscv/rvv/autovec/*
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. 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.) BR, Maxim [1]: https://github.com/llvm/llvm-test-suite/tree/main/MultiSource/Benchmarks/TSVC On Tue, 7 Nov 2023 at 15:53, Jeff Law wrote: > > > > On 11/7/23 05:50, Maxim Blinov wrote: > > Hi all, > > > > I can see about 500 failing tests on the > > vendors/riscv/gcc-13-with-riscv-opts, a mostly-full list at the bottom > > of this email. It's mostly test cases scraping for vector > > instructions. > Correct. There are generic vectorizer changes that would need to be > ported over to that branch to make those tests pass. I looked at this a > few times and ultimately gave up in the rats nest of inter-dependent > patches in the vectorizer. > > > Given the lifetime of that branch is likely nearing its end, I don't > think there's much value left in trying to port those changes over. Any > such effort would likely be better spent nailing down issues on the trunk. > > jeff
Re: Re: Lots of FAILs in gcc.target/riscv/rvv/autovec/*
I am sure that Master GCC has much better VSETVL strategy than GCC-13. And recent evaluation on our internal hardware, shows that master GCC overall is worse than previous RVV GCC I open souce in: https://github.com/riscv-collab/riscv-gcc/tree/riscv-gcc-rvv-next (rvv-next) It's odd, since I think I have support all middle-end features of rvv-next. We are analyzing, and trying to figure out why. We must recover back the performance on GCC-14. juzhe.zh...@rivai.ai From: Maxim Blinov Date: 2023-11-08 12:31 To: Jeff Law CC: gcc; kito.cheng; juzhe.zhong Subject: Re: Lots of FAILs in gcc.target/riscv/rvv/autovec/* 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. 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.) BR, Maxim [1]: https://github.com/llvm/llvm-test-suite/tree/main/MultiSource/Benchmarks/TSVC On Tue, 7 Nov 2023 at 15:53, Jeff Law wrote: > > > > On 11/7/23 05:50, Maxim Blinov wrote: > > Hi all, > > > > I can see about 500 failing tests on the > > vendors/riscv/gcc-13-with-riscv-opts, a mostly-full list at the bottom > > of this email. It's mostly test cases scraping for vector > > instructions. > Correct. There are generic vectorizer changes that would need to be > ported over to that branch to make those tests pass. I looked at this a > few times and ultimately gave up in the rats nest of inter-dependent > patches in the vectorizer. > > > Given the lifetime of that branch is likely nearing its end, I don't > think there's much value left in trying to port those changes over. Any > such effort would likely be better spent nailing down issues on the trunk. > > jeff
Re: Lots of FAILs in gcc.target/riscv/rvv/autovec/*
On Tue, Nov 7, 2023 at 8:33 PM Maxim Blinov via Gcc 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. > > 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. Note TSVC benchmark is part of GCC testsuite too: https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=gcc/testsuite/gcc.dg/vect/tsvc/vect/tsvc;h=0a8f19a630bf39c28c6c6016bbc99a6421d83970;hb=HEAD Thanks, Andrew > > 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.) > > BR, > Maxim > > [1]: > https://github.com/llvm/llvm-test-suite/tree/main/MultiSource/Benchmarks/TSVC > > On Tue, 7 Nov 2023 at 15:53, Jeff Law wrote: > > > > > > > > On 11/7/23 05:50, Maxim Blinov wrote: > > > Hi all, > > > > > > I can see about 500 failing tests on the > > > vendors/riscv/gcc-13-with-riscv-opts, a mostly-full list at the bottom > > > of this email. It's mostly test cases scraping for vector > > > instructions. > > Correct. There are generic vectorizer changes that would need to be > > ported over to that branch to make those tests pass. I looked at this a > > few times and ultimately gave up in the rats nest of inter-dependent > > patches in the vectorizer. > > > > > > Given the lifetime of that branch is likely nearing its end, I don't > > think there's much value left in trying to port those changes over. Any > > such effort would likely be better spent nailing down issues on the trunk. > > > > jeff
