Hi Jeff,
On Thu, Aug 08, 2024 at 09:51:24AM -0600, Jeff Law wrote:
> On 8/8/24 9:13 AM, Mark Wielaard wrote:
> >But I don't fully understand how the gcc testsuite detects whether rvv
> >is implemented. e.g. rvv.exp seems to just check whether the target is
> >RISC-V and if so just executes all tests assuming it can just set
> >-march=rv64gcv* and/or -mrvv-* and run the tests:
> >
> ># Exit immediately if this isn't a RISC-V target.
> >if ![istarget riscv*-*-*] then {
> > return
> >}
> >
> >Should that test be more precise? Or is there some other test that is?
> There's some bits to avoid run tests on targets that don't support
> V. But they may need adjustment to deal with those V0.7.1 systems.
>
> >
> >I do see some of the runtime tests have:
> >/* { dg-do run { target { riscv_v } } } */
> >
> >How exactly does that work? How does it determine the riscv_v target?
> It's all buried inside target-supports.exp.
Found check_effective_target_riscv_v_ok, which tries to execute
vsetivli. Which does work as expected. It is an rvv 1.0 instruction,
so produces an SIGILL on rvv 0.7.1 and so those runtime tests are
skipped as expected.
I did find two tests that use check_vect_support_and_set_flags and
then explicitly use dg-do run even if the effective target doesn't
support riscv_v.
gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c
Which I think just needs to use { dg-do run { target { riscv_v } } }
gcc/testsuite/gcc.dg/vect/pr101145.c
Which I don't know how to "skip".
Is there a generic "dg-require-effective-target supports vect"?
I thought there would be much more, but it turns out all other
failures aren't rvv runtime failures, but compile time failures.
> And yes, there are extreme serialization events in the build. The
> vector implementation for riscv really makes that problem worse.
> insn-recog, insn-output, insn-attrtab and their associated
> generation step can take significant time.
Sam suggested to use STAGE1_CFLAGS="-O2". That seems to help bootstrap
a bit (at least makes those long serialized compiles for those
generated files a bit quicker).
Cheers,
Mark
