Re: [PATCH] RISC-V: THead: Fix missing CFI directives for th.sdd in prologue.
On Wed, Oct 4, 2023 at 9:49 AM Xianmiao Qu wrote:
>
> From: quxm
>
> When generating CFI directives for the store-pair instruction,
> if we add two parallel REG_FRAME_RELATED_EXPR expr_lists like
> (expr_list:REG_FRAME_RELATED_EXPR (set (mem/c:DI (plus:DI (reg/f:DI 2 sp)
> (const_int 8 [0x8])) [1 S8 A64])
> (reg:DI 1 ra))
> (expr_list:REG_FRAME_RELATED_EXPR (set (mem/c:DI (reg/f:DI 2 sp) [1 S8
> A64])
> (reg:DI 8 s0))
> only the first expr_list will be recognized by dwarf2out_frame_debug
> funciton. So, here we generate a SEQUENCE expression of
> REG_FRAME_RELATED_EXPR,
> which includes two sub-expressions of RTX_FRAME_RELATED_P. Then the
> dwarf2out_frame_debug_expr function will iterate through all the
> sub-expressions
> and generate the corresponding CFI directives.
>
> gcc/
> * config/riscv/thead.cc (th_mempair_save_regs): Fix missing CFI
> directives for store-pair instruction.
>
> gcc/testsuite/
> * gcc.target/riscv/xtheadmempair-4.c: New test.
LGTM, I've also tested it.
Reviewed-by: Christoph Müllner
Tested-by: Christoph Müllner
Thanks!
> ---
> gcc/config/riscv/thead.cc | 11 +++
> .../gcc.target/riscv/xtheadmempair-4.c| 29 +++
> 2 files changed, 35 insertions(+), 5 deletions(-)
> create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadmempair-4.c
>
> diff --git a/gcc/config/riscv/thead.cc b/gcc/config/riscv/thead.cc
> index 507c912bc39..be0cd7c1276 100644
> --- a/gcc/config/riscv/thead.cc
> +++ b/gcc/config/riscv/thead.cc
> @@ -366,14 +366,15 @@ th_mempair_save_regs (rtx operands[4])
> {
>rtx set1 = gen_rtx_SET (operands[0], operands[1]);
>rtx set2 = gen_rtx_SET (operands[2], operands[3]);
> + rtx dwarf = gen_rtx_SEQUENCE (VOIDmode, rtvec_alloc (2));
>rtx insn = emit_insn (gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2, set1,
> set2)));
>RTX_FRAME_RELATED_P (insn) = 1;
>
> - REG_NOTES (insn) = alloc_EXPR_LIST (REG_FRAME_RELATED_EXPR,
> - copy_rtx (set1), REG_NOTES (insn));
> -
> - REG_NOTES (insn) = alloc_EXPR_LIST (REG_FRAME_RELATED_EXPR,
> - copy_rtx (set2), REG_NOTES (insn));
> + XVECEXP (dwarf, 0, 0) = copy_rtx (set1);
> + XVECEXP (dwarf, 0, 1) = copy_rtx (set2);
> + RTX_FRAME_RELATED_P (XVECEXP (dwarf, 0, 0)) = 1;
> + RTX_FRAME_RELATED_P (XVECEXP (dwarf, 0, 1)) = 1;
> + add_reg_note (insn, REG_FRAME_RELATED_EXPR, dwarf);
> }
>
> /* Similar like riscv_restore_reg, but restores two registers from memory
> diff --git a/gcc/testsuite/gcc.target/riscv/xtheadmempair-4.c
> b/gcc/testsuite/gcc.target/riscv/xtheadmempair-4.c
> new file mode 100644
> index 000..9aef4e15f8d
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/xtheadmempair-4.c
> @@ -0,0 +1,29 @@
> +/* { dg-do compile } */
> +/* { dg-skip-if "" { *-*-* } { "-O0" "-O1" "-g" "-Oz" "-Os" "-flto" } } */
> +/* { dg-options "-march=rv64gc_xtheadmempair -mtune=thead-c906
> -funwind-tables" { target { rv64 } } } */
> +/* { dg-options "-march=rv32gc_xtheadmempair -mtune=thead-c906
> -funwind-tables" { target { rv32 } } } */
> +
> +extern void bar (void);
> +
> +void foo (void)
> +{
> + asm volatile (";my clobber list"
> + : : : "s0");
> + bar ();
> + asm volatile (";my clobber list"
> + : : : "s0");
> +}
> +
> +/* { dg-final { scan-assembler-times "th.sdd\t" 1 { target { rv64 } } } } */
> +/* { dg-final { scan-assembler ".cfi_offset 8, -16" { target { rv64 } } } }
> */
> +/* { dg-final { scan-assembler ".cfi_offset 1, -8" { target { rv64 } } } } */
> +
> +/* { dg-final { scan-assembler-times "th.swd\t" 1 { target { rv32 } } } } */
> +/* { dg-final { scan-assembler ".cfi_offset 8, -8" { target { rv32 } } } } */
> +/* { dg-final { scan-assembler ".cfi_offset 1, -4" { target { rv32 } } } } */
> +
> +/* { dg-final { scan-assembler ".cfi_restore 1" } } */
> +/* { dg-final { scan-assembler ".cfi_restore 8" } } */
> +
> +/* { dg-final { scan-assembler-times "th.ldd\t" 1 { target { rv64 } } } } */
> +/* { dg-final { scan-assembler-times "th.lwd\t" 1 { target { rv32 } } } } */
> --
> 2.17.1
>
Re: xthead regression with [COMMITTED] RISC-V: const: hide mvconst splitter from IRA
On Mon, Oct 9, 2023 at 10:36 PM Vineet Gupta wrote:
>
> Hi Christoph,
>
> On 10/9/23 12:06, Patrick O'Neill wrote:
> >
> > Hi Vineet,
> >
> > We're seeing a regression on all riscv targets after this patch:|
> >
> > FAIL: gcc.target/riscv/xtheadcondmov-indirect.c -O2
> > check-function-bodies ConNmv_imm_imm_reg||
> > FAIL: gcc.target/riscv/xtheadcondmov-indirect.c -O3 -g
> > check-function-bodies ConNmv_imm_imm_reg
> >
> > Debug log output:
> > body: \taddia[0-9]+,a[0-9]+,-1000+
> > \tlia[0-9]+,9998336+
> > \taddia[0-9]+,a[0-9]+,1664+
> > \tth.mveqza[0-9]+,a[0-9]+,a[0-9]+
> > \tret
> >
> > against: lia5,9998336
> > addia4,a0,-1000
> > addia0,a5,1664
> > th.mveqza0,a1,a4
> > ret|
> >
> > https://github.com/patrick-rivos/gcc-postcommit-ci/issues/8
> > https://github.com/ewlu/riscv-gnu-toolchain/issues/286
> >
>
> It seems with my patch, exactly same instructions get out of order (for
> -O2/-O3) tripping up the test results and differ from say O1 for exact
> same build.
>
> -O2 w/ patch
> ConNmv_imm_imm_reg:
> lia5,9998336
> addia4,a0,-1000
> addia0,a5,1664
> th.mveqza0,a1,a4
> ret
>
> -O1 w/ patch
> ConNmv_imm_imm_reg:
> addia4,a0,-1000
> lia5,9998336
> addia0,a5,1664
> th.mveqza0,a1,a4
> ret
>
> I'm not sure if there is an easy way to handle that.
> Is there a real reason for testing the full sequences verbatim, or is
> testing number of occurrences of th.mv{eqz,nez} enough.
I did not write the test cases, I just merged two non-functional test files
into one that works without changing the actual test approach.
Given that this causes repeated issues, I think that a fall-back to counting
occurrences is the right thing to do.
I can do that if that's ok.
BR
Christoph
> It seems Jeff recently added -fno-sched-pressure to avoid similar issues
> but that apparently is no longer sufficient.
>
> Thx,
> -Vineet
>
> > Thanks,
> > Patrick
> >
> > On 10/6/23 11:22, Vineet Gupta wrote:
> >> Vlad recently introduced a new gate @ira_in_progress, similar to
> >> counterparts @{reload,lra}_in_progress.
> >>
> >> Use this to hide the constant synthesis splitter from being recog* ()
> >> by IRA register equivalence logic which is eager to undo the splits,
> >> generating worse code for constants (and sometimes no code at all).
> >>
> >> See PR/109279 (large constant), PR/110748 (const -0.0) ...
> >>
> >> Granted the IRA logic is subsided with -fsched-pressure which is now
> >> enabled for RISC-V backend, the gate makes this future-proof in
> >> addition to helping with -O1 etc.
> >>
> >> This fixes 1 addition test
> >>
> >> = Summary of gcc testsuite =
> >> | # of unexpected case / # of unique
> >> unexpected case
> >> | gcc | g++ | gfortran |
> >>
> >> rv32imac/ ilp32/ medlow | 416 / 103 | 13 / 6 | 67 /12 |
> >> rv32imafdc/ ilp32d/ medlow | 416 / 103 | 13 / 6 | 24 / 4 |
> >> rv64imac/ lp64/ medlow | 417 / 104 |9 / 3 | 67 /12 |
> >> rv64imafdc/ lp64d/ medlow | 416 / 103 |5 / 2 |6 / 1 |
> >>
> >> Also similar to v1, this doesn't move RISC-V SPEC scores at all.
> >>
> >> gcc/ChangeLog:
> >> * config/riscv/riscv.md (mvconst_internal): Add !ira_in_progress.
> >>
> >> Suggested-by: Jeff Law
> >> Signed-off-by: Vineet Gupta
> >> ---
> >> gcc/config/riscv/riscv.md | 9 ++---
> >> 1 file changed, 6 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
> >> index 1ebe8f92284d..da84b9357bd3 100644
> >> --- a/gcc/config/riscv/riscv.md
> >> +++ b/gcc/config/riscv/riscv.md
> >> @@ -1997,13 +1997,16 @@
> >>
> >> ;; Pretend to have the ability to load complex const_int in order to get
> >> ;; better code generation around them.
> >> -;;
> >> ;; But avoid constants that are special cased elsewhere.
> >> +;;
> >> +;; Hide it from IRA register equiv recog* () to elide potential undoing
> >> of split
> >> +;;
> >> (define_insn_and_split "*mvconst_internal"
> >> [(set (match_operand:GPR 0 "register_operand" "=r")
> >> (match_operand:GPR 1 "splittable_const_int_operand" "i"))]
> >> - "!(p2m1_shift_operand (operands[1], mode)
> >> - || high_mask_shift_operand (operands[1], mode))"
> >> + "!ira_in_progress
> >> + && !(p2m1_shift_operand (operands[1], mode)
> >> +|| high_mask_shift_operand (operands[1], mode))"
> >> "#"
> >> "&& 1"
> >> [(const_int 0)]
>
Re: xthead regression with [COMMITTED] RISC-V: const: hide mvconst splitter from IRA
On Mon, Oct 9, 2023 at 10:48 PM Vineet Gupta wrote: > > On 10/9/23 13:46, Christoph Müllner wrote: > > Given that this causes repeated issues, I think that a fall-back to > > counting occurrences is the right thing to do. I can do that if that's ok. > > Thanks Christoph. Tested patch on list: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632393.html > > -Vineet
Re: [PATCH] RISC-V: Make xtheadcondmov-indirect tests robust against instruction reordering
On Tue, Oct 10, 2023 at 5:08 AM Kito Cheng wrote:
>
> I guess you may also want to clean up those bodies for
> "check-function-bodies"?
I kept the comments on purpose, so that I have a basis for the
expected instruction counts.
But of course, there is no need to follow the format.
Would the following format change of the comments be ok?
-/*
-** ConEmv_imm_imm_reg:
-** addia[0-9]+,a[0-9]+,-1000
-** li a[0-9]+,10
-** th\.mvnez a[0-9]+,a[0-9]+,a[0-9]+
-** ret
-*/
+/* addi aX, aX, -1000
+ li aX, 10
+ th.mvnez aX, aX, aX */
BR
Christoph
>
> On Mon, Oct 9, 2023 at 3:47 PM Christoph Muellner
> wrote:
> >
> > From: Christoph Müllner
> >
> > Fixes: c1bc7513b1d7 ("RISC-V: const: hide mvconst splitter from IRA")
> >
> > A recent change broke the xtheadcondmov-indirect tests, because the order of
> > emitted instructions changed. Since the test is too strict when testing for
> > a fixed instruction order, let's change the tests to simply count
> > instruction,
> > like it is done for similar tests.
> >
> > Reported-by: Patrick O'Neill
> > Signed-off-by: Christoph Müllner
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/riscv/xtheadcondmov-indirect.c: Make robust against
> > instruction reordering.
> >
> > Signed-off-by: Christoph Müllner
> > ---
> > .../gcc.target/riscv/xtheadcondmov-indirect.c | 11 ---
> > 1 file changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/gcc/testsuite/gcc.target/riscv/xtheadcondmov-indirect.c
> > b/gcc/testsuite/gcc.target/riscv/xtheadcondmov-indirect.c
> > index c3253ba5239..eba1b86137b 100644
> > --- a/gcc/testsuite/gcc.target/riscv/xtheadcondmov-indirect.c
> > +++ b/gcc/testsuite/gcc.target/riscv/xtheadcondmov-indirect.c
> > @@ -1,8 +1,7 @@
> > /* { dg-do compile } */
> > -/* { dg-options "-march=rv32gc_xtheadcondmov -fno-sched-pressure" { target
> > { rv32 } } } */
> > -/* { dg-options "-march=rv64gc_xtheadcondmov -fno-sched-pressure" { target
> > { rv64 } } } */
> > +/* { dg-options "-march=rv32gc_xtheadcondmov" { target { rv32 } } } */
> > +/* { dg-options "-march=rv64gc_xtheadcondmov" { target { rv64 } } } */
> > /* { dg-skip-if "" { *-*-* } {"-O0" "-Os" "-Og" "-Oz" "-flto" } } */
> > -/* { dg-final { check-function-bodies "**" "" } } */
> >
> > /*
> > ** ConEmv_imm_imm_reg:
> > @@ -116,3 +115,9 @@ int ConNmv_reg_reg_reg(int x, int y, int z, int n)
> > return z;
> >return n;
> > }
> > +
> > +/* { dg-final { scan-assembler-times "addi\t" 5 } } */
> > +/* { dg-final { scan-assembler-times "li\t" 4 } } */
> > +/* { dg-final { scan-assembler-times "sub\t" 4 } } */
> > +/* { dg-final { scan-assembler-times "th.mveqz\t" 4 } } */
> > +/* { dg-final { scan-assembler-times "th.mvnez\t" 4 } } */
> > --
> > 2.41.0
> >
Re: [PATCH] riscv: thead: Fix failing XTheadCondMov tests (indirect-rv[32|64])
On Wed, Jul 12, 2023 at 4:05 AM Jeff Law wrote: > > > > On 7/10/23 22:44, Christoph Muellner wrote: > > From: Christoph Müllner > > > > Recently, two identical XTheadCondMov tests have been added, which both > > fail. > > Let's fix that by changing the following: > > * Merge both files into one (no need for separate tests for rv32 and rv64) > > * Drop unrelated attribute check test (we already test for `th.mveqz` > >and `th.mvnez` instructions, so there is little additional value) > > * Fix the pattern to allow matching > > > > gcc/testsuite/ChangeLog: > > > > * gcc.target/riscv/xtheadcondmov-indirect-rv32.c: Moved to... > > * gcc.target/riscv/xtheadcondmov-indirect.c: ...here. > > * gcc.target/riscv/xtheadcondmov-indirect-rv64.c: Removed. > I thought this stuff got fixed recently. Certainly happy to see the > files merged though. Here's what I got from the July 4 run: I have the following with a GCC master from today (a454325bea77a0dd79415480d48233a7c296bc0a): FAIL: gcc.target/riscv/xtheadcondmov-indirect-rv32.c -O2 scan-assembler .attribute arch, "rv32i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0_xtheadcondmov1p0" FAIL: gcc.target/riscv/xtheadcondmov-indirect-rv64.c -O2 scan-assembler .attribute arch, "rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0_xtheadcondmov1p0" With this patch the fails are gone. BR Christoph > > > UNSUPPORTED: gcc.target/riscv/xtheadcondmov-indirect-rv32.c -O0 > > UNSUPPORTED: gcc.target/riscv/xtheadcondmov-indirect-rv32.c -O1 > > PASS: gcc.target/riscv/xtheadcondmov-indirect-rv32.c -O2 (test for > > excess errors) > > PASS: gcc.target/riscv/xtheadcondmov-indirect-rv32.c -O2 > > check-function-bodies ConEmv_imm_imm_reg > > PASS: gcc.target/riscv/xtheadcondmov-indirect-rv32.c -O2 > > check-function-bodies ConEmv_imm_reg_reg > > PASS: gcc.target/riscv/xtheadcondmov-indirect-rv32.c -O2 > > check-function-bodies ConEmv_reg_imm_reg > > PASS: gcc.target/riscv/xtheadcondmov-indirect-rv32.c -O2 > > check-function-bodies ConEmv_reg_reg_reg > > PASS: gcc.target/riscv/xtheadcondmov-indirect-rv32.c -O2 > > check-function-bodies ConNmv_imm_imm_reg > > PASS: gcc.target/riscv/xtheadcondmov-indirect-rv32.c -O2 > > check-function-bodies ConNmv_imm_reg_reg > > PASS: gcc.target/riscv/xtheadcondmov-indirect-rv32.c -O2 > > check-function-bodies ConNmv_reg_imm_reg > > PASS: gcc.target/riscv/xtheadcondmov-indirect-rv32.c -O2 > > check-function-bodies ConNmv_reg_reg_reg > > PASS: gcc.target/riscv/xtheadcondmov-indirect-rv32.c -O2 scan-assembler > > .attribute arch, > > "rv32i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0_xtheadcondmov1p0" > > UNSUPPORTED: gcc.target/riscv/xtheadcondmov-indirect-rv32.c -O3 -g > > UNSUPPORTED: gcc.target/riscv/xtheadcondmov-indirect-rv32.c -Os > > UNSUPPORTED: gcc.target/riscv/xtheadcondmov-indirect-rv32.c -O2 -flto > > -fno-use-linker-plugin -flto-partition=none > > UNSUPPORTED: gcc.target/riscv/xtheadcondmov-indirect-rv32.c -O2 -flto > > -fuse-linker-plugin -fno-fat-lto-objects > > UNSUPPORTED: gcc.target/riscv/xtheadcondmov-indirect-rv64.c -O0 > > UNSUPPORTED: gcc.target/riscv/xtheadcondmov-indirect-rv64.c -O1 > > PASS: gcc.target/riscv/xtheadcondmov-indirect-rv64.c -O2 (test for > > excess errors) > > PASS: gcc.target/riscv/xtheadcondmov-indirect-rv64.c -O2 > > check-function-bodies ConEmv_imm_imm_reg > > PASS: gcc.target/riscv/xtheadcondmov-indirect-rv64.c -O2 > > check-function-bodies ConEmv_imm_reg_reg > > PASS: gcc.target/riscv/xtheadcondmov-indirect-rv64.c -O2 > > check-function-bodies ConEmv_reg_imm_reg > > PASS: gcc.target/riscv/xtheadcondmov-indirect-rv64.c -O2 > > check-function-bodies ConEmv_reg_reg_reg > > PASS: gcc.target/riscv/xtheadcondmov-indirect-rv64.c -O2 > > check-function-bodies ConNmv_imm_imm_reg > > PASS: gcc.target/riscv/xtheadcondmov-indirect-rv64.c -O2 > > check-function-bodies ConNmv_imm_reg_reg > > PASS: gcc.target/riscv/xtheadcondmov-indirect-rv64.c -O2 > > check-function-bodies ConNmv_reg_imm_reg > > PASS: gcc.target/riscv/xtheadcondmov-indirect-rv64.c -O2 > > check-function-bodies ConNmv_reg_reg_reg > > PASS: gcc.target/riscv/xtheadcondmov-indirect-rv64.c -O2 scan-assembler > > .attribute arch, > > "rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0_xtheadcondmov1p0" > > UNSUPPORTED: gcc.target/riscv/xtheadcondmov-indirect-rv64.c -O3 -g > > UNSUPPORTED: gcc.target/riscv/xtheadcondmov-indirect-rv64.c -Os > > UNSUPPORTED: gcc.target/riscv/xtheadcondmov-indirect-rv64.c -O2 -flto > > -fno-use-linker-plugin -flto-partition=none > > UNSUPPORTED: gcc.target/riscv/xtheadcondmov-indirect-rv64.c -O2 -flto > > -fuse-linker-plugin -fno-fat-lto-objects > > > jeff
Re: [gcc r14-2455] riscv: Prepare backend for index registers
On Fri, Jul 14, 2023 at 12:28 PM Andreas Schwab wrote: > > Why didn't you test that? Thanks for reporting, and sorry for introducing this warning. I test all patches before sending them. In the case of RISC-V backend patches, I build a 2-stage cross-toolchain and run all regression tests for RV32 and RV64 (using QEMU). Testing is done with and without patches applied to identify regressions. The build process shows a lot of warnings. Therefore I did not investigate finding a way to use -Werror. This means that looking for compiler warnings is a manual step, and I might miss one while scrolling through the logs. Sorry for the inconvenience, Christoph > > ../../gcc/config/riscv/riscv.cc: In function 'int > riscv_regno_ok_for_index_p(int)': > ../../gcc/config/riscv/riscv.cc:864:33: error: unused parameter 'regno' > [-Werror=unused-parameter] > 864 | riscv_regno_ok_for_index_p (int regno) > | ^ > cc1plus: all warnings being treated as errors > make[3]: *** [Makefile:2499: riscv.o] Error 1 > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different."
Re: [gcc r14-2455] riscv: Prepare backend for index registers
On Mon, Jul 17, 2023 at 9:24 AM Andreas Schwab wrote:
>
> On Jul 17 2023, Christoph Müllner wrote:
>
> > The build process shows a lot of warnings.
>
> Then you are using a bad compiler. The build is 100% -Werror clean.
My host compiler is: gcc version 13.1.1 20230614 (Red Hat 13.1.1-4) (GCC)
Some examples:
> /home/cm/src/gcc/riscv-mainline/gcc/text-art/table.cc: In member function
> ‘int text_art::table_geometry::table_x_to_canvas_x(int) const’:
> /home/cm/src/gcc/riscv-mainline/gcc/text-art/table.cc:561:15: warning:
> comparison of integer expressions of different signedness: ‘int’ and
> ‘std::vector::size_type’ {aka ‘long unsigned int’} [-Wsign-compare]
> 561 | if (table_x == m_col_start_x.size ())
> | ^~~~
> /home/cm/src/gcc/riscv-mainline/gcc/text-art/table.cc: In function ‘void
> selftest::test_spans_3()’:
> /home/cm/src/gcc/riscv-mainline/gcc/text-art/table.cc:947:62: warning:
> unquoted keyword ‘char’ in format [-Wformat-diag]
> 947 | "'buf'
> (char[%i])",
> | ^~~~
> /home/cm/src/gcc/riscv-mainline/gcc/gengtype-lex.l: In function ‘int
> yylex(const char**)’:
> gengtype-lex.cc:356:15: warning: this statement may fall through
> [-Wimplicit-fallthrough=]
> 356 | */
> | ~~ ^
> In file included from /home/cm/src/gcc/riscv-mainline/libgcc/unwind-dw2.c:410:
> ./md-unwind-support.h: In function 'riscv_fallback_frame_state':
> ./md-unwind-support.h:67:6: warning: assignment to 'struct sigcontext *' from
> incompatible pointer type 'mcontext_t *' [-Wincompatible-pointer-types]
> 67 | sc = &rt_->uc.uc_mcontext;
> | ^
> /home/cm/src/gcc/riscv-mainline/libgcc/config/riscv/atomic.c:36:8: warning:
> conflicting types for built-in function '__sync_fetch_and_add_1'; expected
> 'unsigned char(volatile void *, unsigned char)'
> [-Wbuiltin-declaration-mismatch]
>36 | type __sync_fetch_and_ ## opname ## _ ## size (type *p, type v)
> \
> |^
Please let me know if I am doing something wrong.
BR
Christoph
>
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
> "And now for something completely different."
Re: [gcc r14-2455] riscv: Prepare backend for index registers
On Mon, Jul 17, 2023 at 9:31 AM Andrew Pinski wrote: > > On Sun, Jul 16, 2023 at 11:49 PM Christoph Müllner > wrote: > > > > On Fri, Jul 14, 2023 at 12:28 PM Andreas Schwab > > wrote: > > > > > > Why didn't you test that? > > > > Thanks for reporting, and sorry for introducing this warning. > > > > I test all patches before sending them. > > In the case of RISC-V backend patches, I build a 2-stage > > cross-toolchain and run all regression tests for RV32 and RV64 (using > > QEMU). > > Testing is done with and without patches applied to identify regressions. > > > > The build process shows a lot of warnings. Therefore I did not > > investigate finding a way to use -Werror. > > This means that looking for compiler warnings is a manual step, and I > > might miss one while scrolling through the logs. > > If you are building a cross compiler, and want to clean up warnings, > first build a native compiler and then build the cross using that. Ok, will adjust my workflow accordingly. > Also maybe it is finding a way to do native bootstraps on riscv to do > testing of patches rather than doing just cross builds when testing > backend patches. > Especially when I have found the GCC testsuite but the bootstrap is > more likely to find backend issues and such. Yes, using the patch-under-testing to build a toolchain can identify issues that the testsuite can't find. I did that a couple of times in a QEMU environment, but I prefer the cross-toolchain approach because it is faster. For patches that have a bigger impact, I test the toolchain with SPEC CPU 2017. Thanks, Christoph > > Thanks, > Andrew > > > > > Sorry for the inconvenience, > > Christoph > > > > > > > > > > ../../gcc/config/riscv/riscv.cc: In function 'int > > > riscv_regno_ok_for_index_p(int)': > > > ../../gcc/config/riscv/riscv.cc:864:33: error: unused parameter 'regno' > > > [-Werror=unused-parameter] > > > 864 | riscv_regno_ok_for_index_p (int regno) > > > | ^ > > > cc1plus: all warnings being treated as errors > > > make[3]: *** [Makefile:2499: riscv.o] Error 1 > > > > > > -- > > > Andreas Schwab, sch...@linux-m68k.org > > > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > > > "And now for something completely different."
Re: [gcc r14-2455] riscv: Prepare backend for index registers
On Mon, Jul 17, 2023 at 9:44 AM Andreas Schwab wrote: > > On Jul 17 2023, Christoph Müllner wrote: > > > My host compiler is: gcc version 13.1.1 20230614 (Red Hat 13.1.1-4) (GCC) > > Too old. Ok understood. Thanks, Christoph > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different."
Re: [PATCH 10/11] riscv: thead: Add support for the XTheadMemIdx ISA extension
On Sat, Jun 10, 2023 at 7:53 PM Jeff Law wrote:
>
>
>
> On 4/28/23 00:23, Christoph Muellner wrote:
> > From: Christoph Müllner
> >
> > The XTheadMemIdx ISA extension provides a additional load and store
> > instructions with new addressing modes.
> >
> > The following memory accesses types are supported:
> > * ltype = [b,bu,h,hu,w,wu,d]
> > * stype = [b,h,w,d]
> >
> > The following addressing modes are supported:
> > * immediate offset with PRE_MODIFY or POST_MODIFY (22 instructions):
> >l.ia, l.ib, s.ia, s.ib
> > * register offset with additional immediate offset (11 instructions):
> >lr, sr
> > * zero-extended register offset with additional immediate offset
> >(11 instructions): lur, sur
> >
> > The RISC-V base ISA does not support index registers, so the changes
> > are kept separate from the RISC-V standard support.
> >
> > Similar like other extensions (Zbb, XTheadBb), this patch needs to
> > prevent the conversion of sign-extensions/zero-extensions into
> > shift instructions. The case of the zero-extended register offset
> > addressing mode is handled by a new peephole pass.
> >
> > Handling the different cases of extensions results in a couple of INSNs
> > that look redundant on first view, but they are just the equivalent
> > of what we already have for Zbb as well. The only difference is, that
> > we have much more load instructions.
> >
> > To fully utilize the capabilities of the instructions, there are
> > a few new peephole passes which fold shift amounts into the RTX
> > if possible. The added tests ensure that this feature won't
> > regress without notice.
> >
> > We already have a constraint with the name 'th_f_fmv', therefore,
> > the new constraints follow this pattern and have the same length
> > as required ('th_m_mia', 'th_m_mib', 'th_m_mir', 'th_m_miu').
> >
> > gcc/ChangeLog:
> >
> > * config/riscv/constraints.md (th_m_mia): New constraint.
> > (th_m_mib): Likewise.
> > (th_m_mir): Likewise.
> > (th_m_miu): Likewise.
> > * config/riscv/riscv-protos.h (enum riscv_address_type):
> > Add new address types ADDRESS_REG_REG, ADDRESS_REG_UREG,
> > and ADDRESS_REG_WB and their documentation.
> > (struct riscv_address_info): Add new field 'shift' and
> > document the field usage for the new address types.
> > (riscv_valid_base_register_p): New prototype.
> > (th_memidx_legitimate_modify_p): Likewise.
> > (th_memidx_legitimate_index_p): Likewise.
> > (th_classify_address): Likewise.
> > (th_output_move): Likewise.
> > (th_print_operand_address): Likewise.
> > * config/riscv/riscv.cc (riscv_index_reg_class):
> > Return GR_REGS for XTheadMemIdx.
> > (riscv_regno_ok_for_index_p): Add support for XTheadMemIdx.
> > (riscv_classify_address): Call th_classify_address() on top.
> > (riscv_output_move): Call th_output_move() on top.
> > (riscv_print_operand_address): Call th_print_operand_address()
> > on top.
> > * config/riscv/riscv.h (HAVE_POST_MODIFY_DISP): New macro.
> > (HAVE_PRE_MODIFY_DISP): Likewise.
> > * config/riscv/riscv.md (zero_extendqi2): Disable
> > for XTheadMemIdx.
> > (*zero_extendqi2_internal): Convert to expand,
> > create INSN with same name and disable it for XTheadMemIdx.
> > (extendsidi2): Likewise.
> > (*extendsidi2_internal): Disable for XTheadMemIdx.
> > * config/riscv/thead-peephole.md: Add helper peephole passes.
> > * config/riscv/thead.cc (valid_signed_immediate): New helper
> > function.
> > (th_memidx_classify_address_modify): New function.
> > (th_memidx_legitimate_modify_p): Likewise.
> > (th_memidx_output_modify): Likewise.
> > (is_memidx_mode): Likewise.
> > (th_memidx_classify_address_index): Likewise.
> > (th_memidx_legitimate_index_p): Likewise.
> > (th_memidx_output_index): Likewise.
> > (th_classify_address): Likewise.
> > (th_output_move): Likewise.
> > (th_print_operand_address): Likewise.
> > * config/riscv/thead.md (*th_memidx_mov2):
> > New INSN.
> > (*th_memidx_zero_extendqi2): Likewise.
> > (*th_memidx_extendsidi2): Likewise
> > (*th_memidx_zero_extendsidi2): Likewise.
> > (*th_memidx_zero_extendhi2): Likewise.
> > (*th_memidx_
Re: [PATCH 11/11] riscv: thead: Add support for the XTheadFMemIdx ISA extension
On Sat, Jun 10, 2023 at 7:54 PM Jeff Law wrote: > > > > On 4/28/23 00:23, Christoph Muellner wrote: > > From: Christoph Müllner > > > > The XTheadFMemIdx ISA extension provides additional load and store > > instructions for floating-point registers with new addressing modes. > > > > The following memory accesses types are supported: > > * ftype = [w,d] (single-precision, double-precision) > > > > The following addressing modes are supported: > > * register offset with additional immediate offset (4 instructions): > >flr, fsr > > * zero-extended register offset with additional immediate offset > >(4 instructions): flur, fsur > > > > These addressing modes are also part of the similar XTheadMemIdx > > ISA extension support, whose code is reused and extended to support > > floating-point registers. > > > > gcc/ChangeLog: > > > > * config/riscv/riscv.cc (riscv_index_reg_class): Also allow > > for XTheadFMemIdx. > > (riscv_regno_ok_for_index_p): Likewise. > > * config/riscv/thead-peephole.md (TARGET_64BIT): > > Generalize peepholes for XTheadFMemIdx. > > * config/riscv/thead.cc (is_fmemidx_mode): New function. > > (th_memidx_classify_address_index): Add support for > > XTheadFMemIdx. > > (th_fmemidx_output_index): New function. > > (th_output_move): Add support for XTheadFMemIdx. > > * config/riscv/thead.md (*th_fmemidx_movsf_hardfloat): New INSN. > > (*th_fmemidx_movdf_hardfloat_rv64): Likewise. > > > > gcc/testsuite/ChangeLog: > > > > * gcc.target/riscv/xtheadmemidx-helpers.h: Add helpers for > > XTheadMemFIdx. > > * gcc.target/riscv/xtheadfmemidx-index-update.c: New test. > > * gcc.target/riscv/xtheadfmemidx-index-xtheadbb-update.c: New test. > > * gcc.target/riscv/xtheadfmemidx-index-xtheadbb.c: New test. > > * gcc.target/riscv/xtheadfmemidx-index.c: New test. > > * gcc.target/riscv/xtheadfmemidx-uindex-update.c: New test. > > * gcc.target/riscv/xtheadfmemidx-uindex-xtheadbb-update.c: New test. > > * gcc.target/riscv/xtheadfmemidx-uindex-xtheadbb.c: New test. > > * gcc.target/riscv/xtheadfmemidx-uindex.c: New test. > Same core questions/comments as in patch #10 of this series. The basic support for this extension is already merged. The documentation can be found here: https://github.com/T-head-Semi/thead-extension-spec/tree/master The extension's name and a link to the documentation has also been registered here: https://github.com/riscv-non-isa/riscv-toolchain-conventions#list-of-vendor-extensions The XTheadFMemIdx extension is part of the T-Head C906 and C910 SoCs. The C906 was launched in October 2021. Thanks, Christoph > > jeff >
Re: [PATCH 10/11] riscv: thead: Add support for the XTheadMemIdx ISA extension
On Wed, Jun 28, 2023 at 8:23 PM Jeff Law wrote: > > > > On 6/28/23 06:39, Christoph Müllner wrote: > > >>> +;; XTheadMemIdx overview: > >>> +;; All peephole passes attempt to improve the operand utilization of > >>> +;; XTheadMemIdx instructions, where one sign or zero extended > >>> +;; register-index-operand can be shifted left by a 2-bit immediate. > >>> +;; > >>> +;; The basic idea is the following optimization: > >>> +;; (set (reg 0) (op (reg 1) (imm 2))) > >>> +;; (set (reg 3) (mem (plus (reg 0) (reg 4))) > >>> +;; ==> > >>> +;; (set (reg 3) (mem (plus (reg 4) (op2 (reg 1) (imm 2 > >>> +;; This optimization only valid if (reg 0) has no further uses. > >> Couldn't this be done by combine if you created define_insn patterns > >> rather than define_peephole2 patterns? Similarly for the other cases > >> handled here. > > > > I was inspired by XTheadMemPair, which merges two memory accesses > > into a mem-pair instruction (and which got inspiration from > > gcc/config/aarch64/aarch64-ldpstp.md). > Right. I'm pretty familiar with those. They cover a different case, > specifically the two insns being optimized don't have a true data > dependency between them. ie, the first instruction does not produce a > result used in the second insn. > > > In the case above there is a data dependency on reg0. ie, the first > instruction generates a result used in the second instruction. combine > is usually the best place to handle the data dependency case. Ok, understood. It is a bit of a special case here, because the peephole is restricted to those cases, where reg0 is not used elsewhere (peep2_reg_dead_p()). I have not seen how to do this for combiner optimizations. I found sh_remove_reg_dead_or_unused_notes(), which tests for reg notes on a given rtx_insn. In our case we have a pattern that matches two insns, where we have to test if one operand (reg0) is dead or unused after the second insn. The first insn can be accessed with "curr_insn", but I did not see how to access the second matching insn. Any ideas or hints? Thanks, Christoph > > > > > > I don't see the benefit of using combine or peephole, but I can change > > if necessary. At least for the provided test cases, the implementation > > works quite well. > Peepholes require the instructions to be consecutive in the stream while > combine relies on data dependence links and can thus find these > opportunities even when the two insn we care about are separated by > unrelated other insns. > > > Jeff
Re: [PATCH 10/11] riscv: thead: Add support for the XTheadMemIdx ISA extension
On Thu, Jun 29, 2023 at 4:09 PM Jeff Law wrote: > > > > On 6/29/23 01:39, Christoph Müllner wrote: > > On Wed, Jun 28, 2023 at 8:23 PM Jeff Law wrote: > >> > >> > >> > >> On 6/28/23 06:39, Christoph Müllner wrote: > >> > >>>>> +;; XTheadMemIdx overview: > >>>>> +;; All peephole passes attempt to improve the operand utilization of > >>>>> +;; XTheadMemIdx instructions, where one sign or zero extended > >>>>> +;; register-index-operand can be shifted left by a 2-bit immediate. > >>>>> +;; > >>>>> +;; The basic idea is the following optimization: > >>>>> +;; (set (reg 0) (op (reg 1) (imm 2))) > >>>>> +;; (set (reg 3) (mem (plus (reg 0) (reg 4))) > >>>>> +;; ==> > >>>>> +;; (set (reg 3) (mem (plus (reg 4) (op2 (reg 1) (imm 2 > >>>>> +;; This optimization only valid if (reg 0) has no further uses. > >>>> Couldn't this be done by combine if you created define_insn patterns > >>>> rather than define_peephole2 patterns? Similarly for the other cases > >>>> handled here. > >>> > >>> I was inspired by XTheadMemPair, which merges two memory accesses > >>> into a mem-pair instruction (and which got inspiration from > >>> gcc/config/aarch64/aarch64-ldpstp.md). > >> Right. I'm pretty familiar with those. They cover a different case, > >> specifically the two insns being optimized don't have a true data > >> dependency between them. ie, the first instruction does not produce a > >> result used in the second insn. > >> > >> > >> In the case above there is a data dependency on reg0. ie, the first > >> instruction generates a result used in the second instruction. combine > >> is usually the best place to handle the data dependency case. > > > > Ok, understood. > > > > It is a bit of a special case here, because the peephole is restricted > > to those cases, where reg0 is not used elsewhere (peep2_reg_dead_p()). > > I have not seen how to do this for combiner optimizations. > If the value is used elsewhere, then the combiner will generate a > parallel with two sets. If the value dies, then the combiner generates > the one set. ie given > > (set (t) (op0 (a) (b))) > (set (r) (op1 (c) (t))) > > If "t" is dead, then combine will present you with: > > (set (r) (op1 (c) (op0 (a) (b > > If "t" is used elsewhere, then combine will present you with: > > (parallel >[(set (r) (op1 (c) (op0 (a) (b > (set (t) (op0 (a) (b)))]) > > Which makes perfect sense if you think about it for a while. If you > still need "t", then the first sequence simply isn't valid as it doesn't > preserve that side effect. Hence it tries to produce a sequence with > the combined operation, but with the side effect of the first statement > included as well. Thanks for this! Of course I was "lucky" and ran into the issue that the patterns did not match, because of unexpected MULT insns where ASHIFTs were expected. But after reading enough of combiner.cc I understood that this is on purpose (for addresses) and I have to adjust my INSNs accordingly. I've changed the patches for XTheadMemIdx and XTheadFMemIdx and will send out a new series. Thanks, Christoph
Re: [PATCH 1/1] riscv: thead: Fix ICE when enable XTheadMemPair ISA extension.
Hi Cooper,
I addressed this in April this year.
It even got an "ok", but nobody pushed it:
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616972.html
BR
Christoph
On Tue, Jul 11, 2023 at 5:39 PM Xianmiao Qu wrote:
>
> The frame related load/store instructions should not been
> scheduled bewteen echo other, and the REG_FRAME_RELATED_EXPR
> expression note should should be added to those instructions
> to prevent this.
> This bug cause ICE during GCC bootstap, and it will also ICE
> in the simplified case mempair-4.c, compilation fails with:
> during RTL pass: dwarf2
> theadmempair-4.c:20:1: internal compiler error: in
> dwarf2out_frame_debug_cfa_offset, at dwarf2cfi.cc:1376
> 0xa8c017 dwarf2out_frame_debug_cfa_offset
> ../../../gcc/gcc/dwarf2cfi.cc:1376
> 0xa8c017 dwarf2out_frame_debug
> ../../../gcc/gcc/dwarf2cfi.cc:2285
> 0xa8c017 scan_insn_after
> ../../../gcc/gcc/dwarf2cfi.cc:2726
> 0xa8cc97 scan_trace
> ../../../gcc/gcc/dwarf2cfi.cc:2893
> 0xa8d84d create_cfi_notes
> ../../../gcc/gcc/dwarf2cfi.cc:2933
> 0xa8d84d execute_dwarf2_frame
> ../../../gcc/gcc/dwarf2cfi.cc:3309
> 0xa8d84d execute
> ../../../gcc/gcc/dwarf2cfi.cc:3799
>
> gcc/ChangeLog:
>
> * config/riscv/thead.cc (th_mempair_save_regs): Add
> REG_FRAME_RELATED_EXPR note for mempair instuctions.
>
> gcc/testsuite/ChangeLog:
> * gcc.target/riscv/xtheadmempair-4.c: New test.
> ---
> gcc/config/riscv/thead.cc | 6 +++--
> .../gcc.target/riscv/xtheadmempair-4.c| 26 +++
> 2 files changed, 30 insertions(+), 2 deletions(-)
> create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadmempair-4.c
>
> diff --git a/gcc/config/riscv/thead.cc b/gcc/config/riscv/thead.cc
> index 75203805310..2df709226f9 100644
> --- a/gcc/config/riscv/thead.cc
> +++ b/gcc/config/riscv/thead.cc
> @@ -366,10 +366,12 @@ th_mempair_save_regs (rtx operands[4])
> {
>rtx set1 = gen_rtx_SET (operands[0], operands[1]);
>rtx set2 = gen_rtx_SET (operands[2], operands[3]);
> + rtx dwarf = gen_rtx_SEQUENCE (VOIDmode, rtvec_alloc (2));
>rtx insn = emit_insn (gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2, set1,
> set2)));
>RTX_FRAME_RELATED_P (insn) = 1;
> - add_reg_note (insn, REG_CFA_OFFSET, copy_rtx (set1));
> - add_reg_note (insn, REG_CFA_OFFSET, copy_rtx (set2));
> + XVECEXP (dwarf, 0, 0) = copy_rtx (set1);
> + XVECEXP (dwarf, 0, 1) = copy_rtx (set2);
> + add_reg_note (insn, REG_FRAME_RELATED_EXPR, dwarf);
> }
>
> /* Similar like riscv_restore_reg, but restores two registers from memory
> diff --git a/gcc/testsuite/gcc.target/riscv/xtheadmempair-4.c
> b/gcc/testsuite/gcc.target/riscv/xtheadmempair-4.c
> new file mode 100644
> index 000..d653f056ef4
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/xtheadmempair-4.c
> @@ -0,0 +1,26 @@
> +/* { dg-do compile } */
> +/* { dg-skip-if "" { *-*-* } { "-O0" "-O1" "-g" "-Oz" "-Os" "-flto" } } */
> +/* { dg-options "-march=rv64gc_xtheadmempair -O2 -g -mtune=thead-c906" {
> target { rv64 } } } */
> +/* { dg-options "-march=rv32gc_xtheadmempair -O2 -g -mtune=thead-c906" {
> target { rv32 } } } */
> +
> +void a();
> +void b(char *);
> +void m_fn1(int);
> +int e;
> +
> +int foo(int ee, int f, int g) {
> + char *h = (char *)__builtin_alloca(1);
> + b(h);
> + b("");
> + int i = ee;
> + e = g;
> + m_fn1(f);
> + a();
> + e = i;
> +}
> +
> +/* { dg-final { scan-assembler-times "th.ldd\t" 3 { target { rv64 } } } } */
> +/* { dg-final { scan-assembler-times "th.sdd\t" 3 { target { rv64 } } } } */
> +
> +/* { dg-final { scan-assembler-times "th.lwd\t" 3 { target { rv32 } } } } */
> +/* { dg-final { scan-assembler-times "th.swd\t" 3 { target { rv32 } } } } */
> --
> 2.17.1
>
Re: [PATCH 1/1] riscv: thead: Fix ICE when enable XTheadMemPair ISA extension.
Hi Kito,
I take some of the blame because I have sent a series
that consisted of fixes followed by new features.
You have ack'ed patches 1-9 from the series.
The last two patches (for XTheadMemIdx and XTheadFMemIdx) were
later reviewed by Jeff and need a bit rework and more testing.
If it helps, you can find patches 1-9 rebased and retested here:
https://github.com/cmuellner/gcc/tree/riscv-thead-improvements
I have also sent out a fix for two failing T-Head tests earlier today:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624049.html
It would be great if you could look at that and push that as well, if it is ok.
Thanks,
Christoph
On Tue, Jul 11, 2023 at 5:51 PM Kito Cheng wrote:
>
> Hi Christoph:
>
> Ooops, I thought Philipp will push those patches, does here any other
> patches got approved but not committed? I can help to push those
> patches tomorrow.
>
> On Tue, Jul 11, 2023 at 11:42 PM Christoph Müllner
> wrote:
> >
> > Hi Cooper,
> >
> > I addressed this in April this year.
> > It even got an "ok", but nobody pushed it:
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616972.html
> >
> > BR
> > Christoph
> >
> > On Tue, Jul 11, 2023 at 5:39 PM Xianmiao Qu
> > wrote:
> > >
> > > The frame related load/store instructions should not been
> > > scheduled bewteen echo other, and the REG_FRAME_RELATED_EXPR
> > > expression note should should be added to those instructions
> > > to prevent this.
> > > This bug cause ICE during GCC bootstap, and it will also ICE
> > > in the simplified case mempair-4.c, compilation fails with:
> > > during RTL pass: dwarf2
> > > theadmempair-4.c:20:1: internal compiler error: in
> > > dwarf2out_frame_debug_cfa_offset, at dwarf2cfi.cc:1376
> > > 0xa8c017 dwarf2out_frame_debug_cfa_offset
> > > ../../../gcc/gcc/dwarf2cfi.cc:1376
> > > 0xa8c017 dwarf2out_frame_debug
> > > ../../../gcc/gcc/dwarf2cfi.cc:2285
> > > 0xa8c017 scan_insn_after
> > > ../../../gcc/gcc/dwarf2cfi.cc:2726
> > > 0xa8cc97 scan_trace
> > > ../../../gcc/gcc/dwarf2cfi.cc:2893
> > > 0xa8d84d create_cfi_notes
> > > ../../../gcc/gcc/dwarf2cfi.cc:2933
> > > 0xa8d84d execute_dwarf2_frame
> > > ../../../gcc/gcc/dwarf2cfi.cc:3309
> > > 0xa8d84d execute
> > > ../../../gcc/gcc/dwarf2cfi.cc:3799
> > >
> > > gcc/ChangeLog:
> > >
> > > * config/riscv/thead.cc (th_mempair_save_regs): Add
> > > REG_FRAME_RELATED_EXPR note for mempair instuctions.
> > >
> > > gcc/testsuite/ChangeLog:
> > > * gcc.target/riscv/xtheadmempair-4.c: New test.
> > > ---
> > > gcc/config/riscv/thead.cc | 6 +++--
> > > .../gcc.target/riscv/xtheadmempair-4.c| 26 +++
> > > 2 files changed, 30 insertions(+), 2 deletions(-)
> > > create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadmempair-4.c
> > >
> > > diff --git a/gcc/config/riscv/thead.cc b/gcc/config/riscv/thead.cc
> > > index 75203805310..2df709226f9 100644
> > > --- a/gcc/config/riscv/thead.cc
> > > +++ b/gcc/config/riscv/thead.cc
> > > @@ -366,10 +366,12 @@ th_mempair_save_regs (rtx operands[4])
> > > {
> > >rtx set1 = gen_rtx_SET (operands[0], operands[1]);
> > >rtx set2 = gen_rtx_SET (operands[2], operands[3]);
> > > + rtx dwarf = gen_rtx_SEQUENCE (VOIDmode, rtvec_alloc (2));
> > >rtx insn = emit_insn (gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2, set1,
> > > set2)));
> > >RTX_FRAME_RELATED_P (insn) = 1;
> > > - add_reg_note (insn, REG_CFA_OFFSET, copy_rtx (set1));
> > > - add_reg_note (insn, REG_CFA_OFFSET, copy_rtx (set2));
> > > + XVECEXP (dwarf, 0, 0) = copy_rtx (set1);
> > > + XVECEXP (dwarf, 0, 1) = copy_rtx (set2);
> > > + add_reg_note (insn, REG_FRAME_RELATED_EXPR, dwarf);
> > > }
> > >
> > > /* Similar like riscv_restore_reg, but restores two registers from memory
> > > diff --git a/gcc/testsuite/gcc.target/riscv/xtheadmempair-4.c
> > > b/gcc/testsuite/gcc.target/riscv/xtheadmempair-4.c
> > > new file mode 100644
> > > index 000..d653f056ef4
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.target/riscv/xtheadmempair-4.c
> > > @@ -0,0 +1,26 @@
> > > +/* { dg-do compile } */
> > > +/* { dg-skip-if "" { *-*-* } { "-O0" "-O1" "-g" "-Oz" "
Re: [PATCH v2 0/2] riscv: Adding support for XTHead(F)MemIdx
On Fri, Oct 20, 2023 at 4:33 PM Jeff Law wrote: > > > > On 10/20/23 03:53, Christoph Muellner wrote: > > From: Christoph Müllner > > > > This two patches add support for the XTheadMemIdx > > and XTheadFMemIdx ISA extensions, that support additional > > addressing modes. The extensions are implemented in a range > > of T-Head cores (e.g. C906, C910, C920) and are available > > on the market for quite some time. > > > > The ISA spec can be found here: > >https://github.com/T-head-Semi/thead-extension-spec > > > > An initial version of these patches has been sent a while ago. > > Jeff Law suggested to use INSNs instead of peepholes to let > > the combiner do the optimization. This is the major change > > that this patches have seen. > Did you happen to do any before/after testing? And if so, did using the > combiner help with discovery of these cases? I would expect it to have > done so, but it's always nice to have a confirmation. I had no doubt this would be equal or better, therefore I did not plan to do that. However, measuring this is not that hard, so I just did the exercise of forward-porting the peephole-based patchset (and all tiny fixes that the v2 has). I then built xalancbmk_r/peak (randomly selected) with both compilers and compared the number of indexed loads and indexed stores in the binary: v1: 3982 indexed loads / 2447 indexed stores v2: 4110 indexed loads (+3.2%) / 2476 indexed stores (+1.2%) So your suggestion indeed helps to discover additional cases. Thanks again for that! BR Christoph
Re: [PATCH v2 1/2] riscv: thead: Add support for the XTheadMemIdx ISA extension
On Sun, Oct 29, 2023 at 10:44 PM Jeff Law wrote:
>
>
>
> On 10/20/23 03:53, Christoph Muellner wrote:
> > From: Christoph Müllner
> >
> > The XTheadMemIdx ISA extension provides a additional load and store
> > instructions with new addressing modes.
> >
> > The following memory accesses types are supported:
> > * load: b,bu,h,hu,w,wu,d
> > * store: b,h,w,d
> >
> > The following addressing modes are supported:
> > * immediate offset with PRE_MODIFY or POST_MODIFY (22 instructions):
> >l.ia, l.ib, s.ia, s.ib
> > * register offset with additional immediate offset (11 instructions):
> >lr, sr
> > * zero-extended register offset with additional immediate offset
> >(11 instructions): lur, sur
> >
> > The RISC-V base ISA does not support index registers, so the changes
> > are kept separate from the RISC-V standard support as much as possible.
> >
> > To combine the shift/multiply instructions into the memory access
> > instructions, this patch comes with a few insn_and_split optimizations
> > that allow the combiner to do this task.
> >
> > Handling the different cases of extensions results in a couple of INSNs
> > that look redundant on first view, but they are just the equivalence
> > of what we already have for Zbb as well. The only difference is, that
> > we have much more load instructions.
> >
> > We already have a constraint with the name 'th_f_fmv', therefore,
> > the new constraints follow this pattern and have the same length
> > as required ('th_m_mia', 'th_m_mib', 'th_m_mir', 'th_m_miu').
> >
> > The added tests ensure that this feature won't regress without notice.
> > Testing: GCC regression test suite, GCC bootstrap build, and
> > SPEC CPU 2017 intrate (base&peak) on C920.
> >
> > Signed-off-by: Christoph Müllner
> >
> > gcc/ChangeLog:
> >
> > * config/riscv/constraints.md (th_m_mia): New constraint.
> > (th_m_mib): Likewise.
> > (th_m_mir): Likewise.
> > (th_m_miu): Likewise.
> > * config/riscv/riscv-protos.h (enum riscv_address_type):
> > Add new address types ADDRESS_REG_REG, ADDRESS_REG_UREG,
> > and ADDRESS_REG_WB and their documentation.
> > (struct riscv_address_info): Add new field 'shift' and
> > document the field usage for the new address types.
> > (riscv_valid_base_register_p): New prototype.
> > (th_memidx_legitimate_modify_p): Likewise.
> > (th_memidx_legitimate_index_p): Likewise.
> > (th_classify_address): Likewise.
> > (th_output_move): Likewise.
> > (th_print_operand_address): Likewise.
> > * config/riscv/riscv.cc (riscv_index_reg_class):
> > Return GR_REGS for XTheadMemIdx.
> > (riscv_regno_ok_for_index_p): Add support for XTheadMemIdx.
> > (riscv_classify_address): Call th_classify_address() on top.
> > (riscv_output_move): Call th_output_move() on top.
> > (riscv_print_operand_address): Call th_print_operand_address()
> > on top.
> > * config/riscv/riscv.h (HAVE_POST_MODIFY_DISP): New macro.
> > (HAVE_PRE_MODIFY_DISP): Likewise.
> > * config/riscv/riscv.md (zero_extendqi2): Disable
> > for XTheadMemIdx.
> > (*zero_extendqi2_internal): Convert to expand,
> > create INSN with same name and disable it for XTheadMemIdx.
> > (extendsidi2): Likewise.
> > (*extendsidi2_internal): Disable for XTheadMemIdx.
> > * config/riscv/thead.cc (valid_signed_immediate): New helper
> > function.
> > (th_memidx_classify_address_modify): New function.
> > (th_memidx_legitimate_modify_p): Likewise.
> > (th_memidx_output_modify): Likewise.
> > (is_memidx_mode): Likewise.
> > (th_memidx_classify_address_index): Likewise.
> > (th_memidx_legitimate_index_p): Likewise.
> > (th_memidx_output_index): Likewise.
> > (th_classify_address): Likewise.
> > (th_output_move): Likewise.
> > (th_print_operand_address): Likewise.
> > * config/riscv/thead.md (*th_memidx_operand): New splitter.
> > (*th_memidx_zero_extendqi2): New INSN.
> > (*th_memidx_extendsidi2): Likewise.
> > (*th_memidx_zero_extendsidi2): Likewise.
> > (*th_memidx_zero_extendhi2): Likewise.
> > (*th_memidx_extend2): Likewise.
> > (*th_memidx_bb_zero_extendsidi2): Likewise.
> > (*th_memidx_bb_zero_extendhi2): Likewise.
&g
Re: [PATCH v2 2/2] riscv: thead: Add support for the XTheadFMemIdx ISA extension
On Sun, Oct 29, 2023 at 11:25 PM Jeff Law wrote: > > > > On 10/20/23 03:53, Christoph Muellner wrote: > > From: Christoph Müllner > > > > The XTheadFMemIdx ISA extension provides additional load and store > > instructions for floating-point registers with new addressing modes. > > > > The following memory accesses types are supported: > > * load/store: [w,d] (single-precision FP, double-precision FP) > > > > The following addressing modes are supported: > > * register offset with additional immediate offset (4 instructions): > >flr, fsr > > * zero-extended register offset with additional immediate offset > >(4 instructions): flur, fsur > > > > These addressing modes are also part of the similar XTheadMemIdx > > ISA extension support, whose code is reused and extended to support > > floating-point registers. > > > > One challenge that this patch needs to solve are GP registers in FP-mode > > (e.g. "(reg:DF a2)"), which cannot be handled by the XTheadFMemIdx > > instructions. Such registers are the result of independent > > optimizations, which can happen after register allocation. > > This patch uses a simple but efficient method to address this: > > add a dependency for XTheadMemIdx to XTheadFMemIdx optimizations. > > This allows to use the instructions from XTheadMemIdx in case > > of such registers. > Or alternately define secondary reloads so that you can get a scratch > register to reload the address into a GPR. Your call on whether or not > to try to implement that. I guess it largely depends on how likely it > is you'll have one extension defined, but not the other. I started doing this but I thought it is not worth the effort, given all cores that implement one extension also support the other. > > The added tests ensure that this feature won't regress without notice. > > Testing: GCC regression test suite and SPEC CPU 2017 intrate (base&peak). > > > > Signed-off-by: Christoph Müllner > > > > gcc/ChangeLog: > > > > * config/riscv/riscv.cc (riscv_index_reg_class): > > Return GR_REGS for XTheadFMemIdx. > > (riscv_regno_ok_for_index_p): Add support for XTheadFMemIdx. > > * config/riscv/riscv.h (HARDFP_REG_P): New macro. > > * config/riscv/thead.cc (is_fmemidx_mode): New function. > > (th_memidx_classify_address_index): Add support for XTheadFMemIdx. > > (th_fmemidx_output_index): New function. > > (th_output_move): Add support for XTheadFMemIdx. > > * config/riscv/thead.md (TH_M_ANYF): New mode iterator. > > (TH_M_NOEXTF): Likewise. > > (*th_fmemidx_movsf_hardfloat): New INSN. > > (*th_fmemidx_movdf_hardfloat_rv64): Likewise. > > (*th_fmemidx_I_a): Likewise. > > (*th_fmemidx_I_c): Likewise. > > (*th_fmemidx_US_a): Likewise. > > (*th_fmemidx_US_c): Likewise. > > (*th_fmemidx_UZ_a): Likewise. > > (*th_fmemidx_UZ_c): Likewise. > > > > gcc/testsuite/ChangeLog: > > > > * gcc.target/riscv/xtheadfmemidx-index-update.c: New test. > > * gcc.target/riscv/xtheadfmemidx-index-xtheadbb-update.c: New test. > > * gcc.target/riscv/xtheadfmemidx-index-xtheadbb.c: New test. > > * gcc.target/riscv/xtheadfmemidx-index.c: New test. > > * gcc.target/riscv/xtheadfmemidx-uindex-update.c: New test. > > * gcc.target/riscv/xtheadfmemidx-uindex-xtheadbb-update.c: New test. > > * gcc.target/riscv/xtheadfmemidx-uindex-xtheadbb.c: New test. > > * gcc.target/riscv/xtheadfmemidx-uindex.c: New test. > > --- > Same note as with the prior patch WRT wrapping assembly instructions > when using scan-assembler. Will do. > > > > > diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h > > index eb162abcb92..1e9813b4f39 100644 > > --- a/gcc/config/riscv/riscv.h > > +++ b/gcc/config/riscv/riscv.h > > @@ -372,6 +372,8 @@ ASM_MISA_SPEC > > ((unsigned int) ((int) (REGNO) - GP_REG_FIRST) < GP_REG_NUM) > > #define FP_REG_P(REGNO) \ > > ((unsigned int) ((int) (REGNO) - FP_REG_FIRST) < FP_REG_NUM) > > +#define HARDFP_REG_P(REGNO) \ > > + ((REGNO) >= FP_REG_FIRST && (REGNO) <= FP_REG_LAST) > > #define V_REG_P(REGNO) \ > > ((unsigned int) ((int) (REGNO) - V_REG_FIRST) < V_REG_NUM) > > #define VL_REG_P(REGNO) ((REGNO) == VL_REGNUM) > > > @@ -755,6 +768,40 @@ th_memidx_output_index (rtx x, machine_mode mode, bool > > load) > > return buf; > > } > > > > +/* Provide a buffer
Re: [RE] [7/7] riscv: Add basic extension support for XTheadFmv and XTheadInt
On Thu, Nov 2, 2023, 08:32 Jin Ma wrote: > Hi, I see that XTheadInt is not implemented in the compiler. Is there any > plan here? > If there is no patch for it, can I try to implement it with you? > Yes, sounds good. Let me know if you have any questions. We don't have any plans to work on this at the moment. BR Christoph > Thanks > > Jin >
Re: [PATCH v3 09/11] riscv: thead: Add support for the XTheadMemPair ISA extension
On Fri, Feb 24, 2023 at 10:01 AM Kito Cheng wrote: > > Got one fail: > > FAIL: gcc.target/riscv/xtheadmempair-1.c -O2 scan-assembler-times > th.luwd\t 4 > > It should scan lwud rather than luwd? Yes, this should be th.lwud. Must have been introduced after testing. I also ran the whole patchset again with RV32 and RV64. This should be the only issue of this kind in the series. Sorry for that!
Re: [PATCH v3 03/11] riscv: thead: Add support for the XTheadBa ISA extension
On Fri, Feb 24, 2023 at 10:54 AM Kito Cheng wrote: > > My impression is that md patterns will use first-match patterns? so > the zba will get higher priority than xtheadba if both patterns are > matched? Yes, I was just about to write this. /opt/riscv-thead/bin/riscv64-unknown-linux-gnu-gcc -O2 -march=rv64gc_zba_xtheadba -mtune=thead-c906 -S ./gcc/testsuite/gcc.target/riscv/xtheadba-addsl.c The resulting xtheadba-addsl.s file has: .attribute arch, "rv64i2p0_m2p0_a2p0_f2p0_d2p0_c2p0_zba1p0_xtheadba1p0" [...] sh1add a0,a1,a0 So the standard extension will be preferred over the custom extension. > > On Fri, Feb 24, 2023 at 2:52 PM Andrew Pinski via Gcc-patches > wrote: > > > > On Thu, Feb 23, 2023 at 9:55 PM Christoph Muellner > > wrote: > > > > > > From: Christoph Müllner > > > > > > This patch adds support for the XTheadBa ISA extension. > > > The new INSN pattern is defined in a new file to separate > > > this vendor extension from the standard extensions. > > > > How does this interact with doing -march=rv32gc_xtheadba_zba ? > > Seems like it might be better handle that case correctly. I suspect > > these all XThreadB* extensions have a similar problem too. > > > > Thanks, > > Andrew Pinski > > > > > > > > gcc/ChangeLog: > > > > > > * config/riscv/riscv.md: Include thead.md > > > * config/riscv/thead.md: New file. > > > > > > gcc/testsuite/ChangeLog: > > > > > > * gcc.target/riscv/xtheadba-addsl.c: New test. > > > > > > Changes in v3: > > > - Fix operand order for th.addsl. > > > > > > Signed-off-by: Christoph Müllner > > > --- > > > gcc/config/riscv/riscv.md | 1 + > > > gcc/config/riscv/thead.md | 31 +++ > > > .../gcc.target/riscv/xtheadba-addsl.c | 55 +++ > > > 3 files changed, 87 insertions(+) > > > create mode 100644 gcc/config/riscv/thead.md > > > create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadba-addsl.c > > > > > > diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md > > > index 05924e9bbf1..d6c2265e9d4 100644 > > > --- a/gcc/config/riscv/riscv.md > > > +++ b/gcc/config/riscv/riscv.md > > > @@ -3093,4 +3093,5 @@ (define_insn "riscv_prefetchi_" > > > (include "pic.md") > > > (include "generic.md") > > > (include "sifive-7.md") > > > +(include "thead.md") > > > (include "vector.md") > > > diff --git a/gcc/config/riscv/thead.md b/gcc/config/riscv/thead.md > > > new file mode 100644 > > > index 000..158e9124c3a > > > --- /dev/null > > > +++ b/gcc/config/riscv/thead.md > > > @@ -0,0 +1,31 @@ > > > +;; Machine description for T-Head vendor extensions > > > +;; Copyright (C) 2021-2022 Free Software Foundation, Inc. > > > + > > > +;; This file is part of GCC. > > > + > > > +;; GCC is free software; you can redistribute it and/or modify > > > +;; it under the terms of the GNU General Public License as published by > > > +;; the Free Software Foundation; either version 3, or (at your option) > > > +;; any later version. > > > + > > > +;; GCC is distributed in the hope that it will be useful, > > > +;; but WITHOUT ANY WARRANTY; without even the implied warranty of > > > +;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > > +;; GNU General Public License for more details. > > > + > > > +;; You should have received a copy of the GNU General Public License > > > +;; along with GCC; see the file COPYING3. If not see > > > +;; <http://www.gnu.org/licenses/>. > > > + > > > +;; XTheadBa > > > + > > > +(define_insn "*th_addsl" > > > + [(set (match_operand:X 0 "register_operand" "=r") > > > + (plus:X (ashift:X (match_operand:X 1 "register_operand" "r") > > > + (match_operand:QI 2 "immediate_operand" "I")) > > > + (match_operand:X 3 "register_operand" "r")))] > > > + "TARGET_XTHEADBA > > > + && (INTVAL (operands[2]) >= 0) && (INTVAL (operands[2]) <= 3)" > > > + "th.addsl\t%0,%3,%1,%2" > > > + [(set_attr "type" "bitmanip") &
Re: [PATCH v3 04/11] riscv: thead: Add support for the XTheadBs ISA extension
On Fri, Feb 24, 2023 at 8:37 AM Kito Cheng wrote: > > > diff --git a/gcc/config/riscv/thead.md b/gcc/config/riscv/thead.md > > index 158e9124c3a..2c684885850 100644 > > --- a/gcc/config/riscv/thead.md > > +++ b/gcc/config/riscv/thead.md > > @@ -29,3 +29,14 @@ (define_insn "*th_addsl" > >"th.addsl\t%0,%3,%1,%2" > >[(set_attr "type" "bitmanip") > > (set_attr "mode" "")]) > > + > > +;; XTheadBs > > + > > +(define_insn "*th_tst" > > + [(set (match_operand:X 0 "register_operand" "=r") > > + (zero_extract:X (match_operand:X 1 "register_operand" "r") > > + (const_int 1) > > + (match_operand 2 "immediate_operand" "i")))] > > + "TARGET_XTHEADBS" > > Add range check like *bexti pattern? > > TARGET_XTHEADBS && UINTVAL (operands[2]) < GET_MODE_BITSIZE (mode) Ok. Thanks, Christoph > > > + "th.tst\t%0,%1,%2" > > + [(set_attr "type" "bitmanip")])
Re: [PATCH v3 03/11] riscv: thead: Add support for the XTheadBa ISA extension
On Fri, Feb 24, 2023 at 11:05 AM Christoph Müllner wrote: > > On Fri, Feb 24, 2023 at 10:54 AM Kito Cheng wrote: > > > > My impression is that md patterns will use first-match patterns? so > > the zba will get higher priority than xtheadba if both patterns are > > matched? > > Yes, I was just about to write this. > > /opt/riscv-thead/bin/riscv64-unknown-linux-gnu-gcc -O2 > -march=rv64gc_zba_xtheadba -mtune=thead-c906 -S > ./gcc/testsuite/gcc.target/riscv/xtheadba-addsl.c > > The resulting xtheadba-addsl.s file has: > .attribute arch, > "rv64i2p0_m2p0_a2p0_f2p0_d2p0_c2p0_zba1p0_xtheadba1p0" > [...] > sh1add a0,a1,a0 > > So the standard extension will be preferred over the custom extension. I tested now with all of them (RV32 and RV64): /opt/riscv-thead/bin/riscv64-unknown-linux-gnu-gcc -O2 -march=rv64gc_zba_xtheadba -mtune=thead-c906 -S ./gcc/testsuite/gcc.target/riscv/xtheadba-addsl.c /opt/riscv-thead/bin/riscv64-unknown-linux-gnu-gcc -O2 -march=rv64gc_zbb_xtheadbb -mtune=thead-c906 -S ./gcc/testsuite/gcc.target/riscv/xtheadbb-ext.c /opt/riscv-thead/bin/riscv64-unknown-linux-gnu-gcc -O2 -march=rv64gc_zbb_xtheadbb -mtune=thead-c906 -S ./gcc/testsuite/gcc.target/riscv/xtheadbb-extu.c /opt/riscv-thead/bin/riscv64-unknown-linux-gnu-gcc -O2 -march=rv64gc_zbb_xtheadbb -mtune=thead-c906 -S ./gcc/testsuite/gcc.target/riscv/xtheadbb-extu-2.c /opt/riscv-thead/bin/riscv64-unknown-linux-gnu-gcc -O2 -march=rv64gc_zbb_xtheadbb -mtune=thead-c906 -S ./gcc/testsuite/gcc.target/riscv/xtheadbb-ff1.c /opt/riscv-thead/bin/riscv64-unknown-linux-gnu-gcc -O2 -march=rv64gc_zbb_xtheadbb -mtune=thead-c906 -S ./gcc/testsuite/gcc.target/riscv/xtheadbb-rev.c /opt/riscv-thead/bin/riscv64-unknown-linux-gnu-gcc -O2 -march=rv64gc_zbb_xtheadbb -mtune=thead-c906 -S ./gcc/testsuite/gcc.target/riscv/xtheadbb-srri.c /opt/riscv-thead/bin/riscv64-unknown-linux-gnu-gcc -O2 -march=rv64gc_zbb_xtheadbs -mtune=thead-c906 -S ./gcc/testsuite/gcc.target/riscv/xtheadbs-tst.c /opt/riscv-thead32/bin/riscv32-unknown-linux-gnu-gcc -O2 -march=rv32gc_zba_xtheadba -mtune=thead-c906 -S ./gcc/testsuite/gcc.target/riscv/xtheadba-addsl.c /opt/riscv-thead32/bin/riscv32-unknown-linux-gnu-gcc -O2 -march=rv32gc_zbb_xtheadbb -mtune=thead-c906 -S ./gcc/testsuite/gcc.target/riscv/xtheadbb-ext.c /opt/riscv-thead32/bin/riscv32-unknown-linux-gnu-gcc -O2 -march=rv32gc_zbb_xtheadbb -mtune=thead-c906 -S ./gcc/testsuite/gcc.target/riscv/xtheadbb-extu.c /opt/riscv-thead32/bin/riscv32-unknown-linux-gnu-gcc -O2 -march=rv32gc_zbb_xtheadbb -mtune=thead-c906 -S ./gcc/testsuite/gcc.target/riscv/xtheadbb-extu-2.c /opt/riscv-thead32/bin/riscv32-unknown-linux-gnu-gcc -O2 -march=rv32gc_zbb_xtheadbb -mtune=thead-c906 -S ./gcc/testsuite/gcc.target/riscv/xtheadbb-ff1.c /opt/riscv-thead32/bin/riscv32-unknown-linux-gnu-gcc -O2 -march=rv32gc_zbb_xtheadbb -mtune=thead-c906 -S ./gcc/testsuite/gcc.target/riscv/xtheadbb-rev.c /opt/riscv-thead32/bin/riscv32-unknown-linux-gnu-gcc -O2 -march=rv32gc_zbb_xtheadbb -mtune=thead-c906 -S ./gcc/testsuite/gcc.target/riscv/xtheadbb-srri.c /opt/riscv-thead32/bin/riscv32-unknown-linux-gnu-gcc -O2 -march=rv32gc_zbb_xtheadbs -mtune=thead-c906 -S ./gcc/testsuite/gcc.target/riscv/xtheadbs-tst.c All behave ok (also when dropping the xtheadb* from the -march). Is it ok to leave this as is? Thanks, Christoph > > > > > > On Fri, Feb 24, 2023 at 2:52 PM Andrew Pinski via Gcc-patches > > wrote: > > > > > > On Thu, Feb 23, 2023 at 9:55 PM Christoph Muellner > > > wrote: > > > > > > > > From: Christoph Müllner > > > > > > > > This patch adds support for the XTheadBa ISA extension. > > > > The new INSN pattern is defined in a new file to separate > > > > this vendor extension from the standard extensions. > > > > > > How does this interact with doing -march=rv32gc_xtheadba_zba ? > > > Seems like it might be better handle that case correctly. I suspect > > > these all XThreadB* extensions have a similar problem too. > > > > > > Thanks, > > > Andrew Pinski > > > > > > > > > > > gcc/ChangeLog: > > > > > > > > * config/riscv/riscv.md: Include thead.md > > > > * config/riscv/thead.md: New file. > > > > > > > > gcc/testsuite/ChangeLog: > > > > > > > > * gcc.target/riscv/xtheadba-addsl.c: New test. > > > > > > > > Changes in v3: > > > > - Fix operand order for th.addsl. > > > > > > > > Signed-off-by: Christoph Müllner > > > > --- > > > > gcc/config/riscv/riscv.md | 1 + > > > > gcc/config/riscv/thead.md
Re: [PATCH v3 00/11] RISC-V: Add XThead* extension support
On Fri, Feb 24, 2023 at 9:09 AM Kito Cheng wrote: > > Hi Christoph: > > OK for trunk for the 1~8, feel free to commit 1~8 after you address > those minor comments, and could you also prepare release notes for > those extensions? I addressed the comment regarding XTheadBs. But I have not done anything regarding XTheadB* and Zb*. Release notes patch can be found here: https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612763.html > And 9~11 needs to take a few more rounds of review and test. I've seen the comments regarding patch 10 and 11. We will try to clean this up asap. In the patch for XTheadMemPair there was this nasty typo in one of the tests, is there anything else that is needed? I believe that patch should be in a better shape than the last two patches and it is much less invasive. Further similar code can be found in other backends. Thanks, Christoph > > > > > On Fri, Feb 24, 2023 at 1:52 PM Christoph Muellner > wrote: > > > > From: Christoph Müllner > > > > This series introduces support for the T-Head specific RISC-V ISA extensions > > which are available e.g. on the T-Head XuanTie C906. > > > > The ISA spec can be found here: > > https://github.com/T-head-Semi/thead-extension-spec > > > > This series adds support for the following XThead* extensions: > > * XTheadBa > > * XTheadBb > > * XTheadBs > > * XTheadCmo > > * XTheadCondMov > > * XTheadFMemIdx > > * XTheadFmv > > * XTheadInt > > * XTheadMac > > * XTheadMemIdx > > * XTheadMemPair > > * XTheadSync > > > > All extensions are properly integrated and the included tests > > demonstrate the improvements of the generated code. > > > > The series also introduces support for "-mcpu=thead-c906", which also > > enables all available XThead* ISA extensions of the T-Head C906. > > > > All patches have been tested and don't introduce regressions for RV32 or > > RV64. > > The patches have also been tested with SPEC CPU2017 on QEMU and real HW > > (D1 board). > > > > Support patches for these extensions for Binutils, QEMU, and LLVM have > > already been merged in the corresponding upstream projects. > > > > Changes in v3: > > - Bugfix in XTheadBa > > - Rewrite of XTheadMemPair > > - Inclusion of XTheadMemIdx and XTheadFMemIdx > > > > Christoph Müllner (9): > > riscv: Add basic XThead* vendor extension support > > riscv: riscv-cores.def: Add T-Head XuanTie C906 > > riscv: thead: Add support for the XTheadBa ISA extension > > riscv: thead: Add support for the XTheadBs ISA extension > > riscv: thead: Add support for the XTheadBb ISA extension > > riscv: thead: Add support for the XTheadCondMov ISA extensions > > riscv: thead: Add support for the XTheadMac ISA extension > > riscv: thead: Add support for the XTheadFmv ISA extension > > riscv: thead: Add support for the XTheadMemPair ISA extension > > > > moiz.hussain (2): > > riscv: thead: Add support for the XTheadMemIdx ISA extension > > riscv: thead: Add support for the XTheadFMemIdx ISA extension > > > > gcc/common/config/riscv/riscv-common.cc | 26 + > > gcc/config/riscv/bitmanip.md | 52 +- > > gcc/config/riscv/constraints.md | 43 + > > gcc/config/riscv/iterators.md |4 + > > gcc/config/riscv/peephole.md | 56 + > > gcc/config/riscv/riscv-cores.def |4 + > > gcc/config/riscv/riscv-opts.h | 29 + > > gcc/config/riscv/riscv-protos.h | 28 +- > > gcc/config/riscv/riscv.cc | 1090 +++-- > > gcc/config/riscv/riscv.h |8 +- > > gcc/config/riscv/riscv.md | 169 ++- > > gcc/config/riscv/riscv.opt|3 + > > gcc/config/riscv/thead.md | 351 ++ > > .../gcc.target/riscv/mcpu-thead-c906.c| 28 + > > .../gcc.target/riscv/xtheadba-addsl.c | 55 + > > gcc/testsuite/gcc.target/riscv/xtheadba.c | 14 + > > gcc/testsuite/gcc.target/riscv/xtheadbb-ext.c | 20 + > > .../gcc.target/riscv/xtheadbb-extu-2.c| 22 + > > .../gcc.target/riscv/xtheadbb-extu.c | 22 + > > gcc/testsuite/gcc.target/riscv/xtheadbb-ff1.c | 18 + > > gcc/testsuite/gcc.target/riscv/xtheadbb-rev.c | 45 + > > .../gcc.target/riscv/xtheadbb-srri.c | 21 + > > gcc/testsuite/gcc.target/riscv/xtheadbb.c | 14 + > > gcc/testsuite/gcc.target/riscv/xthe
Re: [PATCH v3 04/11] riscv: thead: Add support for the XTheadBs ISA extension
On Sun, Feb 26, 2023 at 12:42 AM Hans-Peter Nilsson wrote: > > On Fri, 24 Feb 2023, Christoph Muellner wrote: > > diff --git a/gcc/config/riscv/thead.md b/gcc/config/riscv/thead.md > > index 158e9124c3a..2c684885850 100644 > > --- a/gcc/config/riscv/thead.md > > +++ b/gcc/config/riscv/thead.md > > @@ -29,3 +29,14 @@ (define_insn "*th_addsl" > >"th.addsl\t%0,%3,%1,%2" > >[(set_attr "type" "bitmanip") > > (set_attr "mode" "")]) > > + > > +;; XTheadBs > > + > > +(define_insn "*th_tst" > > + [(set (match_operand:X 0 "register_operand" "=r") > > + (zero_extract:X (match_operand:X 1 "register_operand" "r") > > + (const_int 1) > > + (match_operand 2 "immediate_operand" "i")))] > > (Here and same elsewhere.) > > You're unlikely to get other constant operands in that pattern, > but FWIW, the actual matching pair for just CONST_INT is > "const_int_operand" for the predicate and "n" for the > constraint. Using the right predicate and constraint will also > help the generated part of recog be a few nanoseconds faster. ;) Thank you for that comment! I think what you mean would look like this: (define_insn "*th_tst" [(set (match_operand:X 0 "register_operand" "=r") (zero_extract:X (match_operand:X 1 "register_operand" "r") (match_operand 3 "const_int_operand" "n") (match_operand 2 "immediate_operand" "i")))] "TARGET_XTHEADBS && UINTVAL (operands[2]) < GET_MODE_BITSIZE (mode) && UINTVAL (operands[3]) == 1" "th.tst\t%0,%1,%2" [(set_attr "type" "bitmanip")]) So while we have more generic form in the pattern, the condition needs to check that the operand is equal to 1. I can change this in the patch (I don't have strong opinions about this and I do care about the nanosecond). However, I think this goes beyond this patchset. Because a single git grep shows many examples of "const_int " matches in GCC's backends. Examples can be found in gcc/config/riscv/bitmanip.md, gcc/config/aarch64/aarch64.md,... So it feels like changing the patch to use const_int_operand would go against common practice. @Kito: Any preferences about this? Thanks, Christoph
Re: [PATCH v3 04/11] riscv: thead: Add support for the XTheadBs ISA extension
On Wed, Mar 1, 2023 at 1:19 AM Hans-Peter Nilsson wrote: > > > > On Tue, 28 Feb 2023, Christoph Müllner wrote: > > > On Sun, Feb 26, 2023 at 12:42 AM Hans-Peter Nilsson > > wrote: > > > > > > On Fri, 24 Feb 2023, Christoph Muellner wrote: > > > > diff --git a/gcc/config/riscv/thead.md b/gcc/config/riscv/thead.md > > > > index 158e9124c3a..2c684885850 100644 > > > > --- a/gcc/config/riscv/thead.md > > > > +++ b/gcc/config/riscv/thead.md > > > > @@ -29,3 +29,14 @@ (define_insn "*th_addsl" > > > >"th.addsl\t%0,%3,%1,%2" > > > >[(set_attr "type" "bitmanip") > > > > (set_attr "mode" "")]) > > > > + > > > > +;; XTheadBs > > > > + > > > > +(define_insn "*th_tst" > > > > + [(set (match_operand:X 0 "register_operand" "=r") > > > > + (zero_extract:X (match_operand:X 1 "register_operand" "r") > > > > + (const_int 1) > > > > + (match_operand 2 "immediate_operand" "i")))] > > > > > > (Here and same elsewhere.) > > > > > > You're unlikely to get other constant operands in that pattern, > > > but FWIW, the actual matching pair for just CONST_INT is > > > "const_int_operand" for the predicate and "n" for the > > > constraint. Using the right predicate and constraint will also > > > help the generated part of recog be a few nanoseconds faster. ;) > > > > Thank you for that comment! > > I think what you mean would look like this: > > > > (define_insn "*th_tst" > > [(set (match_operand:X 0 "register_operand" "=r") > > (zero_extract:X (match_operand:X 1 "register_operand" "r") > > (match_operand 3 "const_int_operand" "n") > > (match_operand 2 "immediate_operand" "i")))] > > No; misunderstanding. Keep the (const_int 1) but replace > (match_operand 2 "immediate_operand" "i") with > (match_operand 2 "const_int_operand" "n") Ah, yes, this makes sense! Thanks! > > brgds, H-P
Re: [PATCH] RISC-V: Add Zawrs ISA extension support
On Thu, Oct 27, 2022 at 8:11 PM Christoph Muellner <
christoph.muell...@vrull.eu> wrote:
> From: Christoph Muellner
>
> This patch adds support for the Zawrs ISA extension.
> The patch depends on the corresponding Binutils patch
> to be usable (see [1])
>
> The specification can be found here:
> https://github.com/riscv/riscv-zawrs/blob/main/zawrs.adoc
>
> Note, that the Zawrs extension is not frozen or ratified yet.
> Therefore this patch is an RFC and not intended to get merged.
>
Sorry, forgot to update this part:
The Zawrs extension is frozen but not ratified.
Let me know if I should send a v2 for this change of the commit msg.
Binuitls support has been merged recently:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=eb668e50036e979fb0a74821df4eee0307b44e66
>
> [1] https://sourceware.org/pipermail/binutils/2022-April/120559.html
>
> gcc/ChangeLog:
>
> * common/config/riscv/riscv-common.cc: Add zawrs extension.
> * config/riscv/riscv-opts.h (MASK_ZAWRS): New.
> (TARGET_ZAWRS): New.
> * config/riscv/riscv.opt: New.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/zawrs.c: New test.
>
> Signed-off-by: Christoph Muellner
> ---
> gcc/common/config/riscv/riscv-common.cc | 4
> gcc/config/riscv/riscv-opts.h | 3 +++
> gcc/config/riscv/riscv.opt | 3 +++
> gcc/testsuite/gcc.target/riscv/zawrs.c | 13 +
> 4 files changed, 23 insertions(+)
> create mode 100644 gcc/testsuite/gcc.target/riscv/zawrs.c
>
> diff --git a/gcc/common/config/riscv/riscv-common.cc
> b/gcc/common/config/riscv/riscv-common.cc
> index d6404a01205..4b7f777c103 100644
> --- a/gcc/common/config/riscv/riscv-common.cc
> +++ b/gcc/common/config/riscv/riscv-common.cc
> @@ -163,6 +163,8 @@ static const struct riscv_ext_version
> riscv_ext_version_table[] =
>{"zifencei", ISA_SPEC_CLASS_20191213, 2, 0},
>{"zifencei", ISA_SPEC_CLASS_20190608, 2, 0},
>
> + {"zawrs", ISA_SPEC_CLASS_NONE, 1, 0},
> +
>{"zba", ISA_SPEC_CLASS_NONE, 1, 0},
>{"zbb", ISA_SPEC_CLASS_NONE, 1, 0},
>{"zbc", ISA_SPEC_CLASS_NONE, 1, 0},
> @@ -1180,6 +1182,8 @@ static const riscv_ext_flag_table_t
> riscv_ext_flag_table[] =
>{"zicsr",&gcc_options::x_riscv_zi_subext, MASK_ZICSR},
>{"zifencei", &gcc_options::x_riscv_zi_subext, MASK_ZIFENCEI},
>
> + {"zawrs", &gcc_options::x_riscv_za_subext, MASK_ZAWRS},
> +
>{"zba",&gcc_options::x_riscv_zb_subext, MASK_ZBA},
>{"zbb",&gcc_options::x_riscv_zb_subext, MASK_ZBB},
>{"zbc",&gcc_options::x_riscv_zb_subext, MASK_ZBC},
> diff --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h
> index 1dfe8c89209..25fd85b09b1 100644
> --- a/gcc/config/riscv/riscv-opts.h
> +++ b/gcc/config/riscv/riscv-opts.h
> @@ -73,6 +73,9 @@ enum stack_protector_guard {
> #define TARGET_ZICSR((riscv_zi_subext & MASK_ZICSR) != 0)
> #define TARGET_ZIFENCEI ((riscv_zi_subext & MASK_ZIFENCEI) != 0)
>
> +#define MASK_ZAWRS (1 << 0)
> +#define TARGET_ZAWRS ((riscv_za_subext & MASK_ZAWRS) != 0)
> +
> #define MASK_ZBA (1 << 0)
> #define MASK_ZBB (1 << 1)
> #define MASK_ZBC (1 << 2)
> diff --git a/gcc/config/riscv/riscv.opt b/gcc/config/riscv/riscv.opt
> index 426ea95cd14..7c3ca48d1cc 100644
> --- a/gcc/config/riscv/riscv.opt
> +++ b/gcc/config/riscv/riscv.opt
> @@ -203,6 +203,9 @@ long riscv_stack_protector_guard_offset = 0
> TargetVariable
> int riscv_zi_subext
>
> +TargetVariable
> +int riscv_za_subext
> +
> TargetVariable
> int riscv_zb_subext
>
> diff --git a/gcc/testsuite/gcc.target/riscv/zawrs.c
> b/gcc/testsuite/gcc.target/riscv/zawrs.c
> new file mode 100644
> index 000..0b7e2662343
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/zawrs.c
> @@ -0,0 +1,13 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=rv64gc_zawrs" { target { rv64 } } } */
> +/* { dg-options "-march=rv32gc_zawrs" { target { rv32 } } } */
> +
> +#ifndef __riscv_zawrs
> +#error Feature macro not defined
> +#endif
> +
> +int
> +foo (int a)
> +{
> + return a;
> +}
> --
> 2.37.3
>
>
Re: [PATCH] RISC-V: Add Zawrs ISA extension support
On Thu, Oct 27, 2022 at 10:51 PM Palmer Dabbelt wrote:
> On Thu, 27 Oct 2022 11:23:17 PDT (-0700), christoph.muell...@vrull.eu
> wrote:
> > On Thu, Oct 27, 2022 at 8:11 PM Christoph Muellner <
> > christoph.muell...@vrull.eu> wrote:
> >
> >> From: Christoph Muellner
> >>
> >> This patch adds support for the Zawrs ISA extension.
> >> The patch depends on the corresponding Binutils patch
> >> to be usable (see [1])
> >>
> >> The specification can be found here:
> >> https://github.com/riscv/riscv-zawrs/blob/main/zawrs.adoc
> >>
> >> Note, that the Zawrs extension is not frozen or ratified yet.
> >> Therefore this patch is an RFC and not intended to get merged.
> >>
> >
> > Sorry, forgot to update this part:
> > The Zawrs extension is frozen but not ratified.
> > Let me know if I should send a v2 for this change of the commit msg.
>
> IMO it's fine to just fix it up at commit time. This LGTM, we just need
> the NEWS entry too. I also don't see any build/test results.
>
I ran the GCC regression test suite with rv32 and rv64 toolchains
using the riscv-gnu-toolchain repo and did not see any regressions.
Where can I create the news entry?
>
> Thanks!
>
> > Binuitls support has been merged recently:
> >
> >
> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=eb668e50036e979fb0a74821df4eee0307b44e66
> >
> >
> >>
> >> [1] https://sourceware.org/pipermail/binutils/2022-April/120559.html
> >>
> >> gcc/ChangeLog:
> >>
> >> * common/config/riscv/riscv-common.cc: Add zawrs extension.
> >> * config/riscv/riscv-opts.h (MASK_ZAWRS): New.
> >> (TARGET_ZAWRS): New.
> >> * config/riscv/riscv.opt: New.
> >>
> >> gcc/testsuite/ChangeLog:
> >>
> >> * gcc.target/riscv/zawrs.c: New test.
> >>
> >> Signed-off-by: Christoph Muellner
> >> ---
> >> gcc/common/config/riscv/riscv-common.cc | 4
> >> gcc/config/riscv/riscv-opts.h | 3 +++
> >> gcc/config/riscv/riscv.opt | 3 +++
> >> gcc/testsuite/gcc.target/riscv/zawrs.c | 13 +
> >> 4 files changed, 23 insertions(+)
> >> create mode 100644 gcc/testsuite/gcc.target/riscv/zawrs.c
> >>
> >> diff --git a/gcc/common/config/riscv/riscv-common.cc
> >> b/gcc/common/config/riscv/riscv-common.cc
> >> index d6404a01205..4b7f777c103 100644
> >> --- a/gcc/common/config/riscv/riscv-common.cc
> >> +++ b/gcc/common/config/riscv/riscv-common.cc
> >> @@ -163,6 +163,8 @@ static const struct riscv_ext_version
> >> riscv_ext_version_table[] =
> >>{"zifencei", ISA_SPEC_CLASS_20191213, 2, 0},
> >>{"zifencei", ISA_SPEC_CLASS_20190608, 2, 0},
> >>
> >> + {"zawrs", ISA_SPEC_CLASS_NONE, 1, 0},
> >> +
> >>{"zba", ISA_SPEC_CLASS_NONE, 1, 0},
> >>{"zbb", ISA_SPEC_CLASS_NONE, 1, 0},
> >>{"zbc", ISA_SPEC_CLASS_NONE, 1, 0},
> >> @@ -1180,6 +1182,8 @@ static const riscv_ext_flag_table_t
> >> riscv_ext_flag_table[] =
> >>{"zicsr",&gcc_options::x_riscv_zi_subext, MASK_ZICSR},
> >>{"zifencei", &gcc_options::x_riscv_zi_subext, MASK_ZIFENCEI},
> >>
> >> + {"zawrs", &gcc_options::x_riscv_za_subext, MASK_ZAWRS},
> >> +
> >>{"zba",&gcc_options::x_riscv_zb_subext, MASK_ZBA},
> >>{"zbb",&gcc_options::x_riscv_zb_subext, MASK_ZBB},
> >>{"zbc",&gcc_options::x_riscv_zb_subext, MASK_ZBC},
> >> diff --git a/gcc/config/riscv/riscv-opts.h
> b/gcc/config/riscv/riscv-opts.h
> >> index 1dfe8c89209..25fd85b09b1 100644
> >> --- a/gcc/config/riscv/riscv-opts.h
> >> +++ b/gcc/config/riscv/riscv-opts.h
> >> @@ -73,6 +73,9 @@ enum stack_protector_guard {
> >> #define TARGET_ZICSR((riscv_zi_subext & MASK_ZICSR) != 0)
> >> #define TARGET_ZIFENCEI ((riscv_zi_subext & MASK_ZIFENCEI) != 0)
> >>
> >> +#define MASK_ZAWRS (1 << 0)
> >> +#define TARGET_ZAWRS ((riscv_za_subext & MASK_ZAWRS) != 0)
> >> +
> >> #define MASK_ZBA (1 << 0)
> >> #define MASK_ZBB (1 << 1)
> >> #define MASK_ZBC (1 << 2)
> >> diff --git a/gcc/config/riscv/riscv.opt b/gcc/config/riscv/riscv.opt
> >> index 426ea95cd14..7c3ca48d1cc 100644
> >> --- a/gcc/config/riscv/riscv.opt
> >> +++ b/gcc/config/riscv/riscv.opt
> >> @@ -203,6 +203,9 @@ long riscv_stack_protector_guard_offset = 0
> >> TargetVariable
> >> int riscv_zi_subext
> >>
> >> +TargetVariable
> >> +int riscv_za_subext
> >> +
> >> TargetVariable
> >> int riscv_zb_subext
> >>
> >> diff --git a/gcc/testsuite/gcc.target/riscv/zawrs.c
> >> b/gcc/testsuite/gcc.target/riscv/zawrs.c
> >> new file mode 100644
> >> index 000..0b7e2662343
> >> --- /dev/null
> >> +++ b/gcc/testsuite/gcc.target/riscv/zawrs.c
> >> @@ -0,0 +1,13 @@
> >> +/* { dg-do compile } */
> >> +/* { dg-options "-march=rv64gc_zawrs" { target { rv64 } } } */
> >> +/* { dg-options "-march=rv32gc_zawrs" { target { rv32 } } } */
> >> +
> >> +#ifndef __riscv_zawrs
> >> +#error Feature macro not defined
> >> +#endif
> >> +
> >> +int
> >> +foo (int a)
> >> +{
> >> + return a;
> >> +}
> >> --
> >> 2.37.3
> >>
> >>
>
Re: [PATCH] RISC-V: Add Zawrs ISA extension support
On Wed, Nov 2, 2022 at 3:38 PM Philipp Tomsich wrote:
>
> On Wed, 2 Nov 2022 at 15:21, Christoph Müllner
> wrote:
> >
> >
> >
> > On Thu, Oct 27, 2022 at 10:51 PM Palmer Dabbelt wrote:
> >>
> >> On Thu, 27 Oct 2022 11:23:17 PDT (-0700), christoph.muell...@vrull.eu
> >> wrote:
> >> > On Thu, Oct 27, 2022 at 8:11 PM Christoph Muellner <
> >> > christoph.muell...@vrull.eu> wrote:
> >> >
> >> >> From: Christoph Muellner
> >> >>
> >> >> This patch adds support for the Zawrs ISA extension.
> >> >> The patch depends on the corresponding Binutils patch
> >> >> to be usable (see [1])
> >> >>
> >> >> The specification can be found here:
> >> >> https://github.com/riscv/riscv-zawrs/blob/main/zawrs.adoc
> >> >>
> >> >> Note, that the Zawrs extension is not frozen or ratified yet.
> >> >> Therefore this patch is an RFC and not intended to get merged.
> >> >>
> >> >
> >> > Sorry, forgot to update this part:
> >> > The Zawrs extension is frozen but not ratified.
> >> > Let me know if I should send a v2 for this change of the commit msg.
> >>
> >> IMO it's fine to just fix it up at commit time. This LGTM, we just need
> >> the NEWS entry too. I also don't see any build/test results.
> >
> >
> > I ran the GCC regression test suite with rv32 and rv64 toolchains
> > using the riscv-gnu-toolchain repo and did not see any regressions.
> >
> > Where can I create the news entry?
>
> News are generated from
> git://gcc.gnu.org/git/gcc-wwwdocs.git
>
> You'll want to add to
> htdocs/gcc-13/changes.html
The patch can be found here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/604882.html
Thanks,
Christoph
>
>
> Thanks,
> Philipp.
>
> >>
> >>
> >> Thanks!
> >>
> >> > Binuitls support has been merged recently:
> >> >
> >> > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=eb668e50036e979fb0a74821df4eee0307b44e66
> >> >
> >> >
> >> >>
> >> >> [1] https://sourceware.org/pipermail/binutils/2022-April/120559.html
> >> >>
> >> >> gcc/ChangeLog:
> >> >>
> >> >> * common/config/riscv/riscv-common.cc: Add zawrs extension.
> >> >> * config/riscv/riscv-opts.h (MASK_ZAWRS): New.
> >> >> (TARGET_ZAWRS): New.
> >> >> * config/riscv/riscv.opt: New.
> >> >>
> >> >> gcc/testsuite/ChangeLog:
> >> >>
> >> >> * gcc.target/riscv/zawrs.c: New test.
> >> >>
> >> >> Signed-off-by: Christoph Muellner
> >> >> ---
> >> >> gcc/common/config/riscv/riscv-common.cc | 4
> >> >> gcc/config/riscv/riscv-opts.h | 3 +++
> >> >> gcc/config/riscv/riscv.opt | 3 +++
> >> >> gcc/testsuite/gcc.target/riscv/zawrs.c | 13 +
> >> >> 4 files changed, 23 insertions(+)
> >> >> create mode 100644 gcc/testsuite/gcc.target/riscv/zawrs.c
> >> >>
> >> >> diff --git a/gcc/common/config/riscv/riscv-common.cc
> >> >> b/gcc/common/config/riscv/riscv-common.cc
> >> >> index d6404a01205..4b7f777c103 100644
> >> >> --- a/gcc/common/config/riscv/riscv-common.cc
> >> >> +++ b/gcc/common/config/riscv/riscv-common.cc
> >> >> @@ -163,6 +163,8 @@ static const struct riscv_ext_version
> >> >> riscv_ext_version_table[] =
> >> >>{"zifencei", ISA_SPEC_CLASS_20191213, 2, 0},
> >> >>{"zifencei", ISA_SPEC_CLASS_20190608, 2, 0},
> >> >>
> >> >> + {"zawrs", ISA_SPEC_CLASS_NONE, 1, 0},
> >> >> +
> >> >>{"zba", ISA_SPEC_CLASS_NONE, 1, 0},
> >> >>{"zbb", ISA_SPEC_CLASS_NONE, 1, 0},
> >> >>{"zbc", ISA_SPEC_CLASS_NONE, 1, 0},
> >> >> @@ -1180,6 +1182,8 @@ static const riscv_ext_flag_table_t
> >> >> riscv_ext_flag_table[] =
> >> >>{"zicsr",&gcc_options::x_riscv_zi_subext, MASK_ZICSR},
> >> >>{"zifencei", &gcc_options::x_riscv_zi_subext, MASK_ZIFENCEI},
> >> >>
> >> >> + {"zawrs", &
Re: [PATCH 02/11] riscv: xtheadmempair: Fix CFA reg notes
On Fri, Apr 28, 2023 at 8:12 AM Christoph Muellner wrote: > > From: Christoph Müllner > > The current implementation triggers an assertion in > dwarf2out_frame_debug_cfa_offset() under certain circumstances. > The standard code uses REG_FRAME_RELATED_EXPR notes instead > of REG_CFA_OFFSET notes when saving registers on the stack. > So let's do this as well. > > gcc/ChangeLog: > > * config/riscv/thead.cc (th_mempair_save_regs): > Emit REG_FRAME_RELATED_EXPR notes in prologue. > > Signed-off-by: Christoph Müllner This patch applies cleanly on GCC 13. Ok to backport to GCC 13 (fixing PR114160)? > --- > gcc/config/riscv/thead.cc | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/gcc/config/riscv/thead.cc b/gcc/config/riscv/thead.cc > index 75203805310..d7e3cf80d9b 100644 > --- a/gcc/config/riscv/thead.cc > +++ b/gcc/config/riscv/thead.cc > @@ -368,8 +368,12 @@ th_mempair_save_regs (rtx operands[4]) >rtx set2 = gen_rtx_SET (operands[2], operands[3]); >rtx insn = emit_insn (gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2, set1, > set2))); >RTX_FRAME_RELATED_P (insn) = 1; > - add_reg_note (insn, REG_CFA_OFFSET, copy_rtx (set1)); > - add_reg_note (insn, REG_CFA_OFFSET, copy_rtx (set2)); > + > + REG_NOTES (insn) = alloc_EXPR_LIST (REG_FRAME_RELATED_EXPR, > + copy_rtx (set1), REG_NOTES (insn)); > + > + REG_NOTES (insn) = alloc_EXPR_LIST (REG_FRAME_RELATED_EXPR, > + copy_rtx (set2), REG_NOTES (insn)); > } > > /* Similar like riscv_restore_reg, but restores two registers from memory > -- > 2.40.1 >
[PATCH] RISC-V: Don't add fractional LMUL types to V_VLS for XTheadVector
The expansion of `memset` (via expand_builtin_memset_args())
uses clear_by_pieces() and store_by_pieces() to avoid calls
to the C runtime. To check if a type can be used for that purpose
the function by_pieces_mode_supported_p() tests if a `mov` and
a `vec_duplicate` INSN can be expaned by the backend.
The `vec_duplicate` expansion takes arguments of type `V_VLS`.
The `mov` expansions take arguments of type `V`, `VB`, `VT`,
`VLS_AVL_IMM`, and `VLS_AVL_REG`. Some of these types (in fact
not types but type iterators) include fractional LMUL types.
E.g. `V_VLS` includes `V`, which includes `VI`, which includes
`RVVMF2QI`.
This results in an attempt to use fractional LMUL-types for
the `memset` expansion resulting in an ICE for XTheadVector,
because that extension cannot handle fractional LMULs.
This patch addresses this issue by splitting the definition
of the `VI` mode itereator into `VI_NOFRAC` (without fractional
LMUL types) and `VI_FRAC` (only fractional LMUL types).
Further, it defines `V_VLS` such, that `VI_FRAC` types are only
included if XTheadVector is not enabled.
The effect is demonstrated by a new test case that shows
that the by-pieces framework now emits `sb` instructions
instead of triggering an ICE.
Signed-off-by: Christoph Müllner
PR 114194
gcc/ChangeLog:
* config/riscv/vector-iterators.md: Split VI into VI_FRAC and VI_NOFRAC.
Only include VI_NOFRAC in V_VLS without TARGET_XTHEADVECTOR.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/xtheadvector/pr114194.c: New test.
Signed-off-by: Christoph Müllner
---
gcc/config/riscv/vector-iterators.md | 19 +--
.../riscv/rvv/xtheadvector/pr114194.c | 56 +++
2 files changed, 69 insertions(+), 6 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/pr114194.c
diff --git a/gcc/config/riscv/vector-iterators.md
b/gcc/config/riscv/vector-iterators.md
index c2ea7e8b10a..a24e1bf078f 100644
--- a/gcc/config/riscv/vector-iterators.md
+++ b/gcc/config/riscv/vector-iterators.md
@@ -108,17 +108,24 @@ (define_c_enum "unspecv" [
UNSPECV_FRM_RESTORE_EXIT
])
-(define_mode_iterator VI [
- RVVM8QI RVVM4QI RVVM2QI RVVM1QI RVVMF2QI RVVMF4QI (RVVMF8QI "TARGET_MIN_VLEN
> 32")
-
- RVVM8HI RVVM4HI RVVM2HI RVVM1HI RVVMF2HI (RVVMF4HI "TARGET_MIN_VLEN > 32")
-
- RVVM8SI RVVM4SI RVVM2SI RVVM1SI (RVVMF2SI "TARGET_MIN_VLEN > 32")
+;; Subset of VI with fractional LMUL types
+(define_mode_iterator VI_FRAC [
+ RVVMF2QI RVVMF4QI (RVVMF8QI "TARGET_MIN_VLEN > 32")
+ RVVMF2HI (RVVMF4HI "TARGET_MIN_VLEN > 32")
+ (RVVMF2SI "TARGET_MIN_VLEN > 32")
+])
+;; Subset of VI with non-fractional LMUL types
+(define_mode_iterator VI_NOFRAC [
+ RVVM8QI RVVM4QI RVVM2QI RVVM1QI
+ RVVM8HI RVVM4HI RVVM2HI RVVM1HI
+ RVVM8SI RVVM4SI RVVM2SI RVVM1SI
(RVVM8DI "TARGET_VECTOR_ELEN_64") (RVVM4DI "TARGET_VECTOR_ELEN_64")
(RVVM2DI "TARGET_VECTOR_ELEN_64") (RVVM1DI "TARGET_VECTOR_ELEN_64")
])
+(define_mode_iterator VI [ VI_NOFRAC (VI_FRAC "!TARGET_XTHEADVECTOR") ])
+
;; This iterator is the same as above but with TARGET_VECTOR_ELEN_FP_16
;; changed to TARGET_ZVFH. TARGET_VECTOR_ELEN_FP_16 is also true for
;; TARGET_ZVFHMIN while we actually want to disable all instructions apart
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/pr114194.c
b/gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/pr114194.c
new file mode 100644
index 000..fc2d1349425
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/pr114194.c
@@ -0,0 +1,56 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv32gc_xtheadvector" { target { rv32 } } } */
+/* { dg-options "-march=rv64gc_xtheadvector" { target { rv64 } } } */
+/* { dg-final { check-function-bodies "**" "" } } */
+
+/*
+** foo0_1:
+** sb\tzero,0([a-x0-9]+)
+** ret
+*/
+void foo0_1 (void *p)
+{
+ __builtin_memset (p, 0, 1);
+}
+
+/*
+** foo0_7:
+** sb\tzero,0([a-x0-9]+)
+** sb\tzero,1([a-x0-9]+)
+** sb\tzero,2([a-x0-9]+)
+** sb\tzero,3([a-x0-9]+)
+** sb\tzero,4([a-x0-9]+)
+** sb\tzero,5([a-x0-9]+)
+** sb\tzero,6([a-x0-9]+)
+** ret
+*/
+void foo0_7 (void *p)
+{
+ __builtin_memset (p, 0, 7);
+}
+
+/*
+** foo1_1:
+** li\t[a-x0-9]+,1
+** sb\t[a-x0-9]+,0([a-x0-9]+)
+** ret
+*/
+void foo1_1 (void *p)
+{
+ __builtin_memset (p, 1, 1);
+}
+
+/*
+** foo1_5:
+** li\t[a-x0-9]+,1
+** sb\t[a-x0-9]+,0([a-x0-9]+)
+** sb\t[a-x0-9]+,1([a-x0-9]+)
+** sb\t[a-x0-9]+,2([a-x0-9]+)
+** sb\t[a-x0-9]+,3([a-x0-9]+)
+** sb\t[a-x0-9]+,4([a-x0-9]+)
+** ret
+*/
+void foo1_5 (void *p)
+{
+ __builtin_memset (p, 1, 5);
+}
--
2.44.0
Re: [PATCH] RISC-V: Don't add fractional LMUL types to V_VLS for XTheadVector
On Fri, Mar 22, 2024 at 4:43 AM Bruce Hoult wrote: > > > The effect is demonstrated by a new test case that shows > that the by-pieces framework now emits `sb` instructions > instead of triggering an ICE > > So these small memset() now don't use RVV at all if xtheadvector is enabled? Yes, but not directly. The patch just prevents fractional LMUL modes from being considered for XTheadVector. That's necessary because further lowering memory moves with a fractional LMUL mode cannot be done for XTheadVector (that's the reason for the ICE). > I don't have evidence whether the use of RVV (whether V or > xtheadvector) for these memsets is a win or not, but the treatment > should probably be consistent. > > I don't know why RVV 1.0 uses a fractional LMUL at all here. It would > work perfectly well with LMUL=1 and just setting vl to the appropriate > length (which is always less than 16 bytes). Use of fractional LMUL > doesn't save any resources. The compiler can consider fractional LMUL values for expansion for RVV, but that does not mean it will be used in the emitted instruction sequence. Details like cost model and data alignment also matter. During testing, I observed that RVV and XTheadVector will both emit sequences of 'sd' for short memsets with known length, known data to set, and unknown alignment of the data to be written. However, I have not excessively tested using all possible tuning parameters, as my primary goal was to eliminate the reason for the ICE with XTheadVector. > > On Fri, Mar 22, 2024 at 12:46 PM Christoph Müllner > wrote: > > > > The expansion of `memset` (via expand_builtin_memset_args()) > > uses clear_by_pieces() and store_by_pieces() to avoid calls > > to the C runtime. To check if a type can be used for that purpose > > the function by_pieces_mode_supported_p() tests if a `mov` and > > a `vec_duplicate` INSN can be expaned by the backend. > > > > The `vec_duplicate` expansion takes arguments of type `V_VLS`. > > The `mov` expansions take arguments of type `V`, `VB`, `VT`, > > `VLS_AVL_IMM`, and `VLS_AVL_REG`. Some of these types (in fact > > not types but type iterators) include fractional LMUL types. > > E.g. `V_VLS` includes `V`, which includes `VI`, which includes > > `RVVMF2QI`. > > > > This results in an attempt to use fractional LMUL-types for > > the `memset` expansion resulting in an ICE for XTheadVector, > > because that extension cannot handle fractional LMULs. > > > > This patch addresses this issue by splitting the definition > > of the `VI` mode itereator into `VI_NOFRAC` (without fractional > > LMUL types) and `VI_FRAC` (only fractional LMUL types). > > Further, it defines `V_VLS` such, that `VI_FRAC` types are only > > included if XTheadVector is not enabled. > > > > The effect is demonstrated by a new test case that shows > > that the by-pieces framework now emits `sb` instructions > > instead of triggering an ICE. > > > > Signed-off-by: Christoph Müllner > > > > PR 114194 > > > > gcc/ChangeLog: > > > > * config/riscv/vector-iterators.md: Split VI into VI_FRAC and > > VI_NOFRAC. > > Only include VI_NOFRAC in V_VLS without TARGET_XTHEADVECTOR. > > > > gcc/testsuite/ChangeLog: > > > > * gcc.target/riscv/rvv/xtheadvector/pr114194.c: New test. > > > > Signed-off-by: Christoph Müllner > > --- > > gcc/config/riscv/vector-iterators.md | 19 +-- > > .../riscv/rvv/xtheadvector/pr114194.c | 56 +++ > > 2 files changed, 69 insertions(+), 6 deletions(-) > > create mode 100644 > > gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/pr114194.c > > > > diff --git a/gcc/config/riscv/vector-iterators.md > > b/gcc/config/riscv/vector-iterators.md > > index c2ea7e8b10a..a24e1bf078f 100644 > > --- a/gcc/config/riscv/vector-iterators.md > > +++ b/gcc/config/riscv/vector-iterators.md > > @@ -108,17 +108,24 @@ (define_c_enum "unspecv" [ > >UNSPECV_FRM_RESTORE_EXIT > > ]) > > > > -(define_mode_iterator VI [ > > - RVVM8QI RVVM4QI RVVM2QI RVVM1QI RVVMF2QI RVVMF4QI (RVVMF8QI > > "TARGET_MIN_VLEN > 32") > > - > > - RVVM8HI RVVM4HI RVVM2HI RVVM1HI RVVMF2HI (RVVMF4HI "TARGET_MIN_VLEN > > > 32") > > - > > - RVVM8SI RVVM4SI RVVM2SI RVVM1SI (RVVMF2SI "TARGET_MIN_VLEN > 32") > > +;; Subset of VI with fractional LMUL types > > +(define_mode_iterator VI_FRAC [ > > + RVVMF2QI RVVMF4QI (RVVMF8QI "TARGET_MIN_VLEN > 32") > > + RVVMF2HI (RVVMF4HI
Re: [PATCH] RISC-V: Don't add fractional LMUL types to V_VLS for XTheadVector
On Fri, Mar 22, 2024 at 2:18 AM juzhe.zh...@rivai.ai
wrote:
>
> LGTM.
Pushed.
Thanks!
>
>
> juzhe.zh...@rivai.ai
>
>
> From: Christoph Müllner
> Date: 2024-03-22 07:45
> To: gcc-patches; Kito Cheng; Palmer Dabbelt; Andrew Waterman; Philipp
> Tomsich; Camel Coder; Bruce Hoult; Juzhe-Zhong; Jun Sha; Xianmiao Qu; Jin Ma
> CC: Christoph Müllner
> Subject: [PATCH] RISC-V: Don't add fractional LMUL types to V_VLS for
> XTheadVector
> The expansion of `memset` (via expand_builtin_memset_args())
> uses clear_by_pieces() and store_by_pieces() to avoid calls
> to the C runtime. To check if a type can be used for that purpose
> the function by_pieces_mode_supported_p() tests if a `mov` and
> a `vec_duplicate` INSN can be expaned by the backend.
>
> The `vec_duplicate` expansion takes arguments of type `V_VLS`.
> The `mov` expansions take arguments of type `V`, `VB`, `VT`,
> `VLS_AVL_IMM`, and `VLS_AVL_REG`. Some of these types (in fact
> not types but type iterators) include fractional LMUL types.
> E.g. `V_VLS` includes `V`, which includes `VI`, which includes
> `RVVMF2QI`.
>
> This results in an attempt to use fractional LMUL-types for
> the `memset` expansion resulting in an ICE for XTheadVector,
> because that extension cannot handle fractional LMULs.
>
> This patch addresses this issue by splitting the definition
> of the `VI` mode itereator into `VI_NOFRAC` (without fractional
> LMUL types) and `VI_FRAC` (only fractional LMUL types).
> Further, it defines `V_VLS` such, that `VI_FRAC` types are only
> included if XTheadVector is not enabled.
>
> The effect is demonstrated by a new test case that shows
> that the by-pieces framework now emits `sb` instructions
> instead of triggering an ICE.
>
> Signed-off-by: Christoph Müllner
>
> PR 114194
>
> gcc/ChangeLog:
>
> * config/riscv/vector-iterators.md: Split VI into VI_FRAC and VI_NOFRAC.
> Only include VI_NOFRAC in V_VLS without TARGET_XTHEADVECTOR.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/xtheadvector/pr114194.c: New test.
>
> Signed-off-by: Christoph Müllner
> ---
> gcc/config/riscv/vector-iterators.md | 19 +--
> .../riscv/rvv/xtheadvector/pr114194.c | 56 +++
> 2 files changed, 69 insertions(+), 6 deletions(-)
> create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/pr114194.c
>
> diff --git a/gcc/config/riscv/vector-iterators.md
> b/gcc/config/riscv/vector-iterators.md
> index c2ea7e8b10a..a24e1bf078f 100644
> --- a/gcc/config/riscv/vector-iterators.md
> +++ b/gcc/config/riscv/vector-iterators.md
> @@ -108,17 +108,24 @@ (define_c_enum "unspecv" [
>UNSPECV_FRM_RESTORE_EXIT
> ])
> -(define_mode_iterator VI [
> - RVVM8QI RVVM4QI RVVM2QI RVVM1QI RVVMF2QI RVVMF4QI (RVVMF8QI
> "TARGET_MIN_VLEN > 32")
> -
> - RVVM8HI RVVM4HI RVVM2HI RVVM1HI RVVMF2HI (RVVMF4HI "TARGET_MIN_VLEN > 32")
> -
> - RVVM8SI RVVM4SI RVVM2SI RVVM1SI (RVVMF2SI "TARGET_MIN_VLEN > 32")
> +;; Subset of VI with fractional LMUL types
> +(define_mode_iterator VI_FRAC [
> + RVVMF2QI RVVMF4QI (RVVMF8QI "TARGET_MIN_VLEN > 32")
> + RVVMF2HI (RVVMF4HI "TARGET_MIN_VLEN > 32")
> + (RVVMF2SI "TARGET_MIN_VLEN > 32")
> +])
> +;; Subset of VI with non-fractional LMUL types
> +(define_mode_iterator VI_NOFRAC [
> + RVVM8QI RVVM4QI RVVM2QI RVVM1QI
> + RVVM8HI RVVM4HI RVVM2HI RVVM1HI
> + RVVM8SI RVVM4SI RVVM2SI RVVM1SI
>(RVVM8DI "TARGET_VECTOR_ELEN_64") (RVVM4DI "TARGET_VECTOR_ELEN_64")
>(RVVM2DI "TARGET_VECTOR_ELEN_64") (RVVM1DI "TARGET_VECTOR_ELEN_64")
> ])
> +(define_mode_iterator VI [ VI_NOFRAC (VI_FRAC "!TARGET_XTHEADVECTOR") ])
> +
> ;; This iterator is the same as above but with TARGET_VECTOR_ELEN_FP_16
> ;; changed to TARGET_ZVFH. TARGET_VECTOR_ELEN_FP_16 is also true for
> ;; TARGET_ZVFHMIN while we actually want to disable all instructions apart
> diff --git a/gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/pr114194.c
> b/gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/pr114194.c
> new file mode 100644
> index 000..fc2d1349425
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/pr114194.c
> @@ -0,0 +1,56 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=rv32gc_xtheadvector" { target { rv32 } } } */
> +/* { dg-options "-march=rv64gc_xtheadvector" { target { rv64 } } } */
> +/* { dg-final { check-function-bodies "**" "" } } */
> +
> +/*
> +** foo0_1:
> +** sb\tzero,0([a-x0-9]+)
> +** ret
> +*/
> +void foo0_1 (void *p)
> +{
&g
Re: [PATCH v2] RISC-V: THEAD: Fix improper immediate value for MODIFY_DISP instruction on 32-bit systems.
On Sat, Feb 3, 2024 at 2:11 PM Andreas Schwab wrote: > > On Jan 30 2024, Christoph Müllner wrote: > > > retested > > Nope. Sorry for this. I tested for no regressions in the test suite with a cross-build and QEMU and did not do a Werror bootstrap build. I'll provide a fix for this later today (also breaking the line as it is longer than needed). > > ../../gcc/config/riscv/thead.cc:1144:22: error: invalid suffix on literal; > C++11 requires a space between literal and string macro > [-Werror=literal-suffix] > 1144 | fprintf (file, "(%s),"HOST_WIDE_INT_PRINT_DEC",%u", > reg_names[REGNO (addr.reg)], > | ^ > cc1plus: all warnings being treated as errors > make[3]: *** [../../gcc/config/riscv/t-riscv:127: thead.o] Error 1 > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different."
Re: [PATCH v2] RISC-V: THEAD: Fix improper immediate value for MODIFY_DISP instruction on 32-bit systems.
On Mon, Feb 5, 2024 at 3:56 PM Jeff Law wrote: > > > > On 2/5/24 05:00, Christoph Müllner wrote: > > On Sat, Feb 3, 2024 at 2:11 PM Andreas Schwab > > wrote: > >> > >> On Jan 30 2024, Christoph Müllner wrote: > >> > >>> retested > >> > >> Nope. > > > > Sorry for this. I tested for no regressions in the test suite with a > > cross-build and QEMU and did not do a Werror bootstrap build. I'll > > provide a fix for this later today (also breaking the line as it is > > longer than needed). > Right. And that's pretty standard given the state of the RISC-V > platforms. We've got a platform here that can bootstrap in a reasonable > amount of time, but I haven't set that up in the CI system yet. > > Until such systems are common, these niggling issues are bound to show up. > > It's just whitespace around the HOST_WIDE_INT_PRINT_DEC and wrapping the > long line, right? I've got that in my tree that's bootstrapping now. I > don't mind committing it later today. But if you get to it before my > bootstrap is done, feel free to commit as pre-approved. Pushed: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=184978cd74f962712e813030d58edc109ad9a92d > > jeff
Re: [PATCH] RISC-V: Add new option -march=help to print all supported extensions
On Thu, Feb 15, 2024 at 10:56 AM Kito Cheng wrote: > > The output of -march=help is like below: > > ``` > All available -march extensions for RISC-V: > NameVersion > i 2.0, 2.1 > e 2.0 > m 2.0 > a 2.0, 2.1 > f 2.0, 2.2 > d 2.0, 2.2 > ... > ``` > > Also support -print-supported-extensions and --print-supported-extensions for > clang compatibility. If I remember correctly, then this feature was requested several times in the past. Thanks for working on this! Reviewed-by: Christoph Müllner I have done a quick feature test (no bootstrapping, no check for compiler warnings) as well. Below you find all supported RISC-V extension in today's master branch: All available -march extensions for RISC-V: NameVersion i 2.0, 2.1 e 2.0 m 2.0 a 2.0, 2.1 f 2.0, 2.2 d 2.0, 2.2 c 2.0 v 1.0 h 1.0 zic64b 1.0 zicbom 1.0 zicbop 1.0 zicboz 1.0 ziccamoa1.0 ziccif 1.0 zicclsm 1.0 ziccrse 1.0 zicntr 2.0 zicond 1.0 zicsr 2.0 zifencei2.0 zihintntl 1.0 zihintpause 2.0 zihpm 2.0 zmmul 1.0 za128rs 1.0 za64rs 1.0 zawrs 1.0 zfa 1.0 zfh 1.0 zfhmin 1.0 zfinx 1.0 zdinx 1.0 zca 1.0 zcb 1.0 zcd 1.0 zce 1.0 zcf 1.0 zcmp1.0 zcmt1.0 zba 1.0 zbb 1.0 zbc 1.0 zbkb1.0 zbkc1.0 zbkc1.0 zbkx1.0 zbs 1.0 zk 1.0 zkn 1.0 zknd1.0 zkne1.0 zknh1.0 zkr 1.0 zks 1.0 zksed 1.0 zksh1.0 zkt 1.0 ztso1.0 zvbb1.0 zvbc1.0 zve32f 1.0 zve32x 1.0 zve64d 1.0 zve64f 1.0 zve64x 1.0 zvfbfmin1.0 zvfh1.0 zvfhmin 1.0 zvkb1.0 zvkg1.0 zvkn1.0 zvknc 1.0 zvkned 1.0 zvkng 1.0 zvknha 1.0 zvknhb 1.0 zvks1.0 zvksc 1.0 zvksed 1.0 zvksg 1.0 zvksh 1.0 zvkt1.0 zvl1024b1.0 zvl128b 1.0 zvl16384b 1.0 zvl2048b1.0 zvl256b 1.0 zvl32768b 1.0 zvl32b 1.0 zvl4096b1.0 zvl512b 1.0 zvl64b 1.0 zvl65536b 1.0 zvl8192b1.0 zhinx 1.0 zhinxmin1.0 smaia 1.0 smepmp 1.0 smstateen 1.0 ssaia 1.0 sscofpmf1.0 ssstateen 1.0 sstc1.0 svinval 1.0 svnapot 1.0 svpbmt 1.0 xcvalu 1.0 xcvelw 1.0 xcvmac 1.0 xcvsimd
Re: [PATCH v2] RISC-V: T-HEAD: Add support for the XTheadInt ISA extension
On Tue, Jan 9, 2024 at 6:59 PM Jeff Law wrote: > > > > On 11/17/23 00:33, Jin Ma wrote: > > The XTheadInt ISA extension provides acceleration interruption > > instructions as defined in T-Head-specific: > > * th.ipush > > * th.ipop > > > > Ref: > > https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.3.0/xthead-2023-11-10-2.3.0.pdf > > > > gcc/ChangeLog: > > > > * config/riscv/riscv-protos.h (th_int_get_mask): New prototype. > > (th_int_get_save_adjustment): Likewise. > > (th_int_adjust_cfi_prologue): Likewise. > > * config/riscv/riscv.cc (TH_INT_INTERRUPT): New macro. > > (riscv_expand_prologue): Add the processing of XTheadInt. > > (riscv_expand_epilogue): Likewise. > > * config/riscv/riscv.md: New unspec. > > * config/riscv/thead.cc (BITSET_P): New macro. > > * config/riscv/thead.md (th_int_push): New pattern. > > (th_int_pop): New pattern. > > > > gcc/testsuite/ChangeLog: > > > > * gcc.target/riscv/xtheadint-push-pop.c: New test. > Thanks for the ping earlier today. I've looked at this patch repeatedly > over the last few weeks, but never enough to give it a full review. > > > > diff --git a/gcc/config/riscv/thead.md b/gcc/config/riscv/thead.md > > index 2babfafb23c..4d6e16c0edc 100644 > > --- a/gcc/config/riscv/thead.md > > +++ b/gcc/config/riscv/thead.md > > > +(define_insn "th_int_pop" > > + [(unspec_volatile [(const_int 0)] UNSPECV_XTHEADINT_POP) > > + (clobber (reg:SI RETURN_ADDR_REGNUM)) > > + (clobber (reg:SI T0_REGNUM)) > > + (clobber (reg:SI T1_REGNUM)) > > + (clobber (reg:SI T2_REGNUM)) > > + (clobber (reg:SI A0_REGNUM)) > > + (clobber (reg:SI A1_REGNUM)) > > + (clobber (reg:SI A2_REGNUM)) > > + (clobber (reg:SI A3_REGNUM)) > > + (clobber (reg:SI A4_REGNUM)) > > + (clobber (reg:SI A5_REGNUM)) > > + (clobber (reg:SI A6_REGNUM)) > > + (clobber (reg:SI A7_REGNUM)) > > + (clobber (reg:SI T3_REGNUM)) > > + (clobber (reg:SI T4_REGNUM)) > > + (clobber (reg:SI T5_REGNUM)) > > + (clobber (reg:SI T6_REGNUM)) > > + (return)] > > + "TARGET_XTHEADINT && !TARGET_64BIT" > > + "th.ipop" > > + [(set_attr "type" "ret") > > + (set_attr "mode" "SI")]) > I probably would have gone with a load type since its the loads that are > most likely to interact existing code in the pipeline. But I doubt it > really matters in practice. > > > OK for the trunk. Thanks for your patience. I've retested this locally (no regressions), completed the ChangeLog in the commit message and committed. Thanks, Christoph
Re: [PATCH] RISC-V: THEAD: Fix ICE caused by split optimizations for XTheadFMemIdx.
On Thu, Jan 11, 2024 at 4:36 PM Kito Cheng wrote:
>
> LGTM
>
> On Thu, Jan 11, 2024 at 7:23 PM Jin Ma wrote:
> >
> > Due to the premature split optimizations for XTheadFMemIdx, GPR
> > is allocated when reload allocates registers, resulting in the
> > following insn.
LGTM.
This was most likely not detected so far, because it only affects rv32
(test focus on xthead(f)memidx was rv64).
I've rebased, retested (no regressions) and pushed.
Thanks,
Christoph
> >
> > (insn 66 21 64 5 (set (reg:DF 14 a4 [orig:136 ] [136])
> > (mem:DF (plus:SI (reg/f:SI 15 a5 [141])
> > (ashift:SI (reg/v:SI 10 a0 [orig:137 i ] [137])
> > (const_int 3 [0x3]))) [0 S8 A64])) 218
> > {*movdf_hardfloat_rv32}
> > (nil))
> >
> > Since we currently do not support adjustments to th_m_mir/th_m_miu,
> > which will trigger ICE. So it is recommended to place the split
> > optimizations after reload to ensure FPR when registers are allocated.
> >
> > gcc/ChangeLog:
> >
> > * config/riscv/thead.md: Add limits for splits.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/riscv/xtheadfmemidx-medany.c: New test.
> > ---
> > gcc/config/riscv/thead.md | 22 ---
> > .../gcc.target/riscv/xtheadfmemidx-medany.c | 38 +++
> > 2 files changed, 54 insertions(+), 6 deletions(-)
> > create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadfmemidx-medany.c
> >
> > diff --git a/gcc/config/riscv/thead.md b/gcc/config/riscv/thead.md
> > index e370774d518..5c7d4beb1b6 100644
> > --- a/gcc/config/riscv/thead.md
> > +++ b/gcc/config/riscv/thead.md
> > @@ -933,14 +933,17 @@ (define_insn_and_split "*th_fmemidx_I_a"
> > && pow2p_hwi (INTVAL (operands[2]))
> > && IN_RANGE (exact_log2 (INTVAL (operands[2])), 1, 3)"
> >"#"
> > - "&& 1"
> > + "&& reload_completed"
> >[(set (match_dup 0)
> > (mem:TH_M_NOEXTF (plus:X
> >(match_dup 3)
> >(ashift:X (match_dup 1) (match_dup 2)]
> >{ operands[2] = GEN_INT (exact_log2 (INTVAL (operands [2])));
> >}
> > -)
> > + [(set_attr "move_type" "fpload")
> > + (set_attr "mode" "")
> > + (set_attr "type" "fmove")
> > + (set (attr "length") (const_int 16))])
> >
> > (define_insn_and_split "*th_fmemidx_I_c"
> >[(set (mem:TH_M_ANYF (plus:X
> > @@ -977,7 +980,7 @@ (define_insn_and_split "*th_fmemidx_US_a"
> > && CONST_INT_P (operands[3])
> > && (INTVAL (operands[3]) >> exact_log2 (INTVAL (operands[2]))) ==
> > 0x"
> >"#"
> > - "&& 1"
> > + "&& reload_completed"
> >[(set (match_dup 0)
> > (mem:TH_M_NOEXTF (plus:DI
> >(match_dup 4)
> > @@ -985,7 +988,10 @@ (define_insn_and_split "*th_fmemidx_US_a"
> >{ operands[1] = gen_lowpart (SImode, operands[1]);
> > operands[2] = GEN_INT (exact_log2 (INTVAL (operands [2])));
> >}
> > -)
> > + [(set_attr "move_type" "fpload")
> > + (set_attr "mode" "")
> > + (set_attr "type" "fmove")
> > + (set (attr "length") (const_int 16))])
> >
> > (define_insn_and_split "*th_fmemidx_US_c"
> >[(set (mem:TH_M_ANYF (plus:DI
> > @@ -1020,12 +1026,16 @@ (define_insn_and_split "*th_fmemidx_UZ_a"
> >"TARGET_64BIT && TARGET_XTHEADMEMIDX && TARGET_XTHEADFMEMIDX
> > && (!HARD_REGISTER_NUM_P (REGNO (operands[0])) || HARDFP_REG_P (REGNO
> > (operands[0])))"
> >"#"
> > - "&& 1"
> > + "&& reload_completed"
> >[(set (match_dup 0)
> > (mem:TH_M_NOEXTF (plus:DI
> >(match_dup 2)
> >(zero_extend:DI (match_dup 1)]
> > -)
> > + ""
> > + [(set_attr "move_type" "fpload")
> > + (set_attr "mode" "")
> > + (set_attr "type" "fmove")
> > + (set (attr "length") (const_int 16))])
> >
> > (define_insn_and_split "*th_fmemidx_UZ_c"
> >[(set (mem:TH_M_ANYF (plus:DI
> > diff --git a/gcc/testsuite/gcc.target/riscv/xtheadfmemidx-medany.c
> > b/gcc/testsuite/gcc.target/riscv/xtheadfmemidx-medany.c
> > new file mode 100644
> > index 000..0c8060d0632
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/riscv/xtheadfmemidx-medany.c
> > @@ -0,0 +1,38 @@
> > +/* { dg-do compile } */
> > +/* { dg-skip-if "" { *-*-* } { "-O0" "-O1" "-O3" "-Og" "-Os" "-Oz"} } */
> > +/* { dg-options "-march=rv32gc_xtheadfmemidx_xtheadfmv_xtheadmemidx
> > -mabi=ilp32d -mcmodel=medany -O2" } */
> > +
> > +typedef union {
> > + double v;
> > + unsigned w;
> > +} my_t;
> > +
> > +double z;
> > +
> > +double foo (int i, int j)
> > +{
> > +
> > + if (j)
> > +{
> > + switch (i)
> > + {
> > + case 0:
> > + return 1;
> > + case 1:
> > + return 0;
> > + case 2:
> > + return 3.0;
> > + }
> > +}
> > +
> > + if (i == 1)
> > +{
> > + my_t u;
> > + u.v = z;
> > + u.w = 1;
> > + z = u.v;
> > +}
> > + return z;
> > +}
> > +
> > +/* { dg-final { scan-assembler-times {\mth\.flrd\M} 1 } } */
> > --
> > 2.17.1
> >
Re: [PATCH v4 0/3] RISC-V: Add intrinsics for Bitmanip and Scalar Crypto extensions
On Mon, Jan 15, 2024 at 9:35 AM Liao Shihua wrote:
>
> Update v3 -> v4:
> 1.Typo fix.
> 2.Only test *intrinsic-32 on rv32 and *intrinsic-64 on rv64.
> 3.Update Copyright year to 2024.
Thanks, for fixing the rv32/rv64 issues!
I've tested this series: no regressions and all new tests pass.
I've also reviewed this series again, and I think it is ready.
I can push once a maintainer approves (e.g. Kito or Jeff).
Thanks for working on this!
>
> Update v2 -> v3:
> 1. Change pattern mode form X to GPR in orcb, clmul, and brev8.
> 2. Add emulated testsuite.
> 3. Removed duplicate testsuite between built-in and intrinsic.
> 4. Typo fix.
>
> Update v1 -> v2:
> 1. Rename *_intrinsic-* to *_intrinsic-XLEN.
> 2. Typo fix.
> 3. Intrinsics with immediate arguments will use marcos at O0 .
>
> It's a little patch add just provides a mapping from the RV intrinsics to the
> builtin
> names within GCC.
>
> Liao Shihua (3):
> RISC-V: Remove the Scalar Bitmanip and Crypto Built-In function
> testsuites
> RISC-V: Add C intrinsic for Scalar Crypto Extension
> RISC-V: Add C intrinsic for Scalar Bitmanip Extension
>
> gcc/config.gcc| 2 +-
> gcc/config/riscv/bitmanip.md | 10 +-
> gcc/config/riscv/crypto.md| 4 +-
> gcc/config/riscv/riscv-builtins.cc| 22 ++
> gcc/config/riscv/riscv-cmo.def| 12 +-
> gcc/config/riscv/riscv-ftypes.def | 2 +
> gcc/config/riscv/riscv-scalar-crypto.def | 22 +-
> gcc/config/riscv/riscv_bitmanip.h | 297 +
> gcc/config/riscv/riscv_crypto.h | 309 ++
> .../riscv/scalar_bitmanip_intrinsic-32.c | 97 ++
> .../scalar_bitmanip_intrinsic-64-emulated.c | 33 ++
> .../riscv/scalar_bitmanip_intrinsic-64.c | 115 +++
> .../riscv/scalar_crypto_intrinsic-32.c| 115 +++
> .../riscv/scalar_crypto_intrinsic-64.c| 123 +++
> .../gcc.target/riscv/zbb_32_bswap-1.c | 11 -
> gcc/testsuite/gcc.target/riscv/zbb_bswap-1.c | 11 -
> gcc/testsuite/gcc.target/riscv/zbb_bswap-2.c | 12 -
> .../riscv/{zbb_32_bswap-2.c => zbb_bswap16.c} | 3 +-
> gcc/testsuite/gcc.target/riscv/zbbw.c | 26 --
> gcc/testsuite/gcc.target/riscv/zbc32.c| 23 --
> gcc/testsuite/gcc.target/riscv/zbc64.c| 23 --
> gcc/testsuite/gcc.target/riscv/zbkb32.c | 18 -
> gcc/testsuite/gcc.target/riscv/zbkb64.c | 5 -
> gcc/testsuite/gcc.target/riscv/zbkc32.c | 17 -
> gcc/testsuite/gcc.target/riscv/zbkc64.c | 17 -
> gcc/testsuite/gcc.target/riscv/zbkx32.c | 18 -
> gcc/testsuite/gcc.target/riscv/zbkx64.c | 18 -
> gcc/testsuite/gcc.target/riscv/zknd32-2.c | 28 --
> gcc/testsuite/gcc.target/riscv/zknd64-2.c | 42 ---
> gcc/testsuite/gcc.target/riscv/zkne32-2.c | 28 --
> gcc/testsuite/gcc.target/riscv/zkne64-2.c | 34 --
> .../gcc.target/riscv/zknh-sha256-32.c | 10 -
> .../gcc.target/riscv/zknh-sha256-64.c | 28 --
> .../gcc.target/riscv/zknh-sha512-32.c | 42 ---
> .../gcc.target/riscv/zknh-sha512-64.c | 31 --
> gcc/testsuite/gcc.target/riscv/zksed32-2.c| 29 --
> gcc/testsuite/gcc.target/riscv/zksed64-2.c| 29 --
> gcc/testsuite/gcc.target/riscv/zksh32.c | 19 --
> gcc/testsuite/gcc.target/riscv/zksh64.c | 19 --
> 39 files changed, 1149 insertions(+), 555 deletions(-)
> create mode 100644 gcc/config/riscv/riscv_bitmanip.h
> create mode 100644 gcc/config/riscv/riscv_crypto.h
> create mode 100644
> gcc/testsuite/gcc.target/riscv/scalar_bitmanip_intrinsic-32.c
> create mode 100644
> gcc/testsuite/gcc.target/riscv/scalar_bitmanip_intrinsic-64-emulated.c
> create mode 100644
> gcc/testsuite/gcc.target/riscv/scalar_bitmanip_intrinsic-64.c
> create mode 100644
> gcc/testsuite/gcc.target/riscv/scalar_crypto_intrinsic-32.c
> create mode 100644
> gcc/testsuite/gcc.target/riscv/scalar_crypto_intrinsic-64.c
> delete mode 100644 gcc/testsuite/gcc.target/riscv/zbb_32_bswap-1.c
> delete mode 100644 gcc/testsuite/gcc.target/riscv/zbb_bswap-1.c
> delete mode 100644 gcc/testsuite/gcc.target/riscv/zbb_bswap-2.c
> rename gcc/testsuite/gcc.target/riscv/{zbb_32_bswap-2.c => zbb_bswap16.c}
> (59%)
> delete mode 100644 gcc/testsuite/gcc.target/riscv/zbbw.c
> delete mode 100644 gcc/testsuite/gcc.target/riscv/zbc32.c
> delete mode 100644 gcc/testsuite/gcc.target/riscv/zbc64.c
> delete mode 100644 gcc/testsuite/gcc.target/riscv/zbkc32.c
> delete mode 100644 gcc/testsuite/gcc.target/riscv/zbkc64.c
> delete mode 100644 gcc/testsuite/gcc.target/riscv/zbkx32.c
> delete mode 100644 gcc/testsuite/gcc.target/riscv/zbkx64.c
> delete mode 100644 gcc/testsuite/gcc.target/riscv/zknd32-2.c
> delete mode 100644 gcc/testsuite/gcc.target/riscv/zknd64-2.c
> delete mode 100644 gcc/testsuite/gcc.target/riscv/zkne32-2.c
> delete mode 100644 gcc/testsuit
Re: [PATCH v4 0/3] RISC-V: Add intrinsics for Bitmanip and Scalar Crypto extensions
On Mon, Jan 15, 2024 at 4:35 PM Kito Cheng wrote:
>
> Ok :)
I've re-created changelog entries in commit messages (commit hook
rejected the commits)
and pushed.
Thanks,
Christoph
>
>
> Christoph Müllner 於 2024年1月15日 週一 23:17 寫道：
>>
>> On Mon, Jan 15, 2024 at 9:35 AM Liao Shihua wrote:
>> >
>> > Update v3 -> v4:
>> > 1.Typo fix.
>> > 2.Only test *intrinsic-32 on rv32 and *intrinsic-64 on rv64.
>> > 3.Update Copyright year to 2024.
>>
>> Thanks, for fixing the rv32/rv64 issues!
>> I've tested this series: no regressions and all new tests pass.
>> I've also reviewed this series again, and I think it is ready.
>> I can push once a maintainer approves (e.g. Kito or Jeff).
>>
>> Thanks for working on this!
>>
>> >
>> > Update v2 -> v3:
>> > 1. Change pattern mode form X to GPR in orcb, clmul, and brev8.
>> > 2. Add emulated testsuite.
>> > 3. Removed duplicate testsuite between built-in and intrinsic.
>> > 4. Typo fix.
>> >
>> > Update v1 -> v2:
>> > 1. Rename *_intrinsic-* to *_intrinsic-XLEN.
>> > 2. Typo fix.
>> > 3. Intrinsics with immediate arguments will use marcos at O0 .
>> >
>> > It's a little patch add just provides a mapping from the RV intrinsics to
>> > the builtin
>> > names within GCC.
>> >
>> > Liao Shihua (3):
>> > RISC-V: Remove the Scalar Bitmanip and Crypto Built-In function
>> > testsuites
>> > RISC-V: Add C intrinsic for Scalar Crypto Extension
>> > RISC-V: Add C intrinsic for Scalar Bitmanip Extension
>> >
>> > gcc/config.gcc| 2 +-
>> > gcc/config/riscv/bitmanip.md | 10 +-
>> > gcc/config/riscv/crypto.md| 4 +-
>> > gcc/config/riscv/riscv-builtins.cc| 22 ++
>> > gcc/config/riscv/riscv-cmo.def| 12 +-
>> > gcc/config/riscv/riscv-ftypes.def | 2 +
>> > gcc/config/riscv/riscv-scalar-crypto.def | 22 +-
>> > gcc/config/riscv/riscv_bitmanip.h | 297 +
>> > gcc/config/riscv/riscv_crypto.h | 309 ++
>> > .../riscv/scalar_bitmanip_intrinsic-32.c | 97 ++
>> > .../scalar_bitmanip_intrinsic-64-emulated.c | 33 ++
>> > .../riscv/scalar_bitmanip_intrinsic-64.c | 115 +++
>> > .../riscv/scalar_crypto_intrinsic-32.c| 115 +++
>> > .../riscv/scalar_crypto_intrinsic-64.c| 123 +++
>> > .../gcc.target/riscv/zbb_32_bswap-1.c | 11 -
>> > gcc/testsuite/gcc.target/riscv/zbb_bswap-1.c | 11 -
>> > gcc/testsuite/gcc.target/riscv/zbb_bswap-2.c | 12 -
>> > .../riscv/{zbb_32_bswap-2.c => zbb_bswap16.c} | 3 +-
>> > gcc/testsuite/gcc.target/riscv/zbbw.c | 26 --
>> > gcc/testsuite/gcc.target/riscv/zbc32.c| 23 --
>> > gcc/testsuite/gcc.target/riscv/zbc64.c| 23 --
>> > gcc/testsuite/gcc.target/riscv/zbkb32.c | 18 -
>> > gcc/testsuite/gcc.target/riscv/zbkb64.c | 5 -
>> > gcc/testsuite/gcc.target/riscv/zbkc32.c | 17 -
>> > gcc/testsuite/gcc.target/riscv/zbkc64.c | 17 -
>> > gcc/testsuite/gcc.target/riscv/zbkx32.c | 18 -
>> > gcc/testsuite/gcc.target/riscv/zbkx64.c | 18 -
>> > gcc/testsuite/gcc.target/riscv/zknd32-2.c | 28 --
>> > gcc/testsuite/gcc.target/riscv/zknd64-2.c | 42 ---
>> > gcc/testsuite/gcc.target/riscv/zkne32-2.c | 28 --
>> > gcc/testsuite/gcc.target/riscv/zkne64-2.c | 34 --
>> > .../gcc.target/riscv/zknh-sha256-32.c | 10 -
>> > .../gcc.target/riscv/zknh-sha256-64.c | 28 --
>> > .../gcc.target/riscv/zknh-sha512-32.c | 42 ---
>> > .../gcc.target/riscv/zknh-sha512-64.c | 31 --
>> > gcc/testsuite/gcc.target/riscv/zksed32-2.c| 29 --
>> > gcc/testsuite/gcc.target/riscv/zksed64-2.c| 29 --
>> > gcc/testsuite/gcc.target/riscv/zksh32.c | 19 --
>> > gcc/testsuite/gcc.target/riscv/zksh64.c | 19 --
>> > 39 files changed, 1149 insertions(+), 555 deletions(-)
>> > create mode 100644 gcc/config/riscv/riscv_bitmanip.h
>> > create mode 100644 gcc/config/riscv/riscv_crypto.h
>> > create mode 100644
>> > gcc/testsuite/gcc.target/riscv/scalar_bitmanip_intrinsic-32.c
>> > create mode 100644
>> > gcc/testsuite/gcc.target/r
Re: [PATCH v5] RISC-V: Support XTheadVector extension
On Fri, Jan 12, 2024 at 4:18 AM Jun Sha (Joshua) wrote: > > This patch series presents gcc implementation of the XTheadVector > extension [1]. > > [1] https://github.com/T-head-Semi/thead-extension-spec/ > > For some vector patterns that cannot be avoided, we use > "!TARGET_XTHEADVECTOR" to disable them in order not to > generate instructions that xtheadvector does not support, > causing 10 changes in vector.md. > > For the th. prefix issue, we use current_output_insn and > the ASM_OUTPUT_OPCODE hook instead of directly modifying > patterns in vector.md. > > We have run the GCC test suite and can confirm that there > are no regressions. > > Furthermore, we have run the tests in > https://github.com/riscv-non-isa/rvv-intrinsic-doc/tree/main/examples, > and all the tests passed. > > Co-authored-by: Jin Ma > Co-authored-by: Xianmiao Qu > Co-authored-by: Christoph Müllner > > [PATCH v4] RISC-V: Introduce XTheadVector as a subset of V1.0.0 > [PATCH v5] RISC-V: Adds the prefix "th." for the instructions of XTheadVector > [PATCH v6] RISC-V: Handle differences between XTheadvector and Vector > [PATCH v6] RISC-V: Add support for xtheadvector-specific intrinsics > [PATCH v6] RISC-V: Fix register overlap issue for some xtheadvector > instructions > [PATCH v5] RISC-V: Rewrite some instructions using ASM targethook All patches of this series got either "LGTM" or "OK": * https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643339.html * https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642798.html * https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642799.html * https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642800.html * https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642801.html * https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642802.html As mentioned earlier, I have rebased the patches, retested them locally and (after ensuring there are no regressions) pushed them. To all involved people: thank you very much! A special 'thank you' goes to Juzhe, who did a great job in reviewing the patches and providing suggestions to get the code into shape!
Re: [PATCH v2] RISC-V: THEAD: Fix improper immediate value for MODIFY_DISP instruction on 32-bit systems.
On Mon, Jan 29, 2024 at 1:32 PM Kito Cheng wrote: > > LGTM I've rebased, retested (rv64+rv32) and merged this patch. Thanks! > > Jin Ma 於 2024年1月29日 週一 17:57 寫道： >> >> When using '%ld' to print 'long long int' variable, 'fprintf' will >> produce messy output on a 32-bit system, in an incorrect instruction >> being generated, such as 'th.lwib a1,(a0),-16,4294967295'. And the >> following error occurred during compilation: >> >> Assembler messages: >> Error: improper immediate value (18446744073709551615) >> >> gcc/ChangeLog: >> >> * config/riscv/thead.cc (th_print_operand_address): Change %ld >> to %lld. >> --- >> gcc/config/riscv/thead.cc | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/gcc/config/riscv/thead.cc b/gcc/config/riscv/thead.cc >> index 2955bc5f8a9..e4b8c37bc28 100644 >> --- a/gcc/config/riscv/thead.cc >> +++ b/gcc/config/riscv/thead.cc >> @@ -1141,7 +1141,7 @@ th_print_operand_address (FILE *file, machine_mode >> mode, rtx x) >>return true; >> >> case ADDRESS_REG_WB: >> - fprintf (file, "(%s),%ld,%u", reg_names[REGNO (addr.reg)], >> + fprintf (file, "(%s),"HOST_WIDE_INT_PRINT_DEC",%u", reg_names[REGNO >> (addr.reg)], >>INTVAL (addr.offset) >> addr.shift, addr.shift); >> return true; >> >> -- >> 2.17.1 >>
[PATCH] riscv: Move UNSPEC_XTHEAD* from unspecv to unspec
The UNSPEC_XTHEAD* macros ended up in the unspecv enum, which broke gcc/testsuite/gcc.target/riscv/xtheadfmv-fmv.c. The INSNs expect these unspecs to be not volatile. Further, there is not reason to have them defined volatile. So let's simply move the macros into the unspec enum. With this patch we have again 0 fails in riscv.exp. gcc/ChangeLog: * config/riscv/riscv.md: Move UNSPEC_XTHEADFMV* to unspec enum. Signed-off-by: Christoph Müllner --- gcc/config/riscv/riscv.md | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md index edcaec4a786..b320ad0210e 100644 --- a/gcc/config/riscv/riscv.md +++ b/gcc/config/riscv/riscv.md @@ -89,6 +89,10 @@ (define_c_enum "unspec" [ ;; Workaround for HFmode without hardware extension UNSPEC_FMV_SFP16_X + + ;; XTheadFmv moves + UNSPEC_XTHEADFMV + UNSPEC_XTHEADFMV_HW ]) (define_c_enum "unspecv" [ @@ -127,10 +131,6 @@ (define_c_enum "unspecv" [ ;; Zihintpause unspec UNSPECV_PAUSE - ;; XTheadFmv unspec - UNSPEC_XTHEADFMV - UNSPEC_XTHEADFMV_HW - ;; XTheadInt unspec UNSPECV_XTHEADINT_PUSH UNSPECV_XTHEADINT_POP -- 2.43.0
Re: [PR target/110201] Fix operand types for various scalar crypto insns
On Tue, Jun 20, 2023 at 12:34 AM Jeff Law via Gcc-patches wrote: > > > A handful of the scalar crypto instructions are supposed to take a > constant integer argument 0..3 inclusive. A suitable constraint was > created and used for this purpose (D03), but the operand's predicate is > "register_operand". That's just wrong. > > This patch adds a new predicate "const_0_3_operand" and fixes the > relevant insns to use it. One could argue the constraint is redundant > now (and you'd be correct). I wouldn't lose sleep if someone wanted > that removed, in which case I'll spin up a V2. > > The testsuite was broken in a way that made it consistent with the > compiler, so the tests passed, when they really should have been issuing > errors all along. > > This patch adjusts the existing tests so that they all expect a > diagnostic on the invalid operand usage (including out of range > constants). It adds new tests with proper constants, testing the > extremes of valid values. > > OK for the trunk, or should we remove the D03 constraint? Reviewed-by: Christoph Muellner The patch does not apply cleanly anymore, because there were some small changes in crypto.md.
Re: [PATCH] RISC-V: fix scalar crypto pattern
On Thu, Dec 14, 2023 at 1:40 AM Jeff Law wrote: > On 12/13/23 02:03, Christoph Müllner wrote: > > On Wed, Dec 13, 2023 at 9:22 AM Liao Shihua wrote: > >> > >> In Scalar Crypto Built-In functions, some require immediate parameters, > >> But register_operand are incorrectly used in the pattern. > >> > >> E.g.: > >> __builtin_riscv_aes64ks1i(rs1,1) > >> Before: > >>li a5,1 > >>aes64ks1i a0,a0,a5 > >> > >>Assembler messages: > >>Error: instruction aes64ks1i requires absolute expression > >> > >> After: > >>aes64ks1i a0,a0,1 > > > > Looks good to me (also tested with rv32 and rv64). > > (I was actually surprised that the D03 constraint was not sufficient) > > > > Reviewed-by: Christoph Muellner > > Tested-by: Christoph Muellner > > > > Nit: I would prefer to separate arguments with a comma followed by a space. > > Even if the existing code was not written like that. > > E.g. __builtin_riscv_sm4ed(rs1,rs2,1); -> __builtin_riscv_sm4ed(rs1, rs2, > > 1); > > > > I propose to remove the builtin tests for scalar crypto and scalar bitmanip > > as part of the patchset that adds the intrinsic tests (no value in > > duplicated tests). > > > >> gcc/ChangeLog: > >> > >> * config/riscv/crypto.md: Use immediate_operand instead of > >> register_operand. > You should mention the actual patterns changed. > > I would strongly recommend adding some tests that out of range cases are > rejected (out of range constants as well as a variable for that last > argument). I did that in my patch from June to fix this problem (which > was never acked/reviewed). Sorry, I was not aware of this patch. Since Jeff's patch was here first and also includes more tests, I propose to move forward with his patch (but I'm not a maintainer!). Therefore, I've reviewed Jeff's patch and replied to his email. FWIW: Jeff's patch can be found here: https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622233.html
Re: [PR target/110201] Fix operand types for various scalar crypto insns
On Fri, Dec 15, 2023 at 12:36 AM Jeff Law wrote: > > > > On 12/14/23 02:46, Christoph Müllner wrote: > > On Tue, Jun 20, 2023 at 12:34 AM Jeff Law via Gcc-patches > > wrote: > >> > >> > >> A handful of the scalar crypto instructions are supposed to take a > >> constant integer argument 0..3 inclusive. A suitable constraint was > >> created and used for this purpose (D03), but the operand's predicate is > >> "register_operand". That's just wrong. > >> > >> This patch adds a new predicate "const_0_3_operand" and fixes the > >> relevant insns to use it. One could argue the constraint is redundant > >> now (and you'd be correct). I wouldn't lose sleep if someone wanted > >> that removed, in which case I'll spin up a V2. > >> > >> The testsuite was broken in a way that made it consistent with the > >> compiler, so the tests passed, when they really should have been issuing > >> errors all along. > >> > >> This patch adjusts the existing tests so that they all expect a > >> diagnostic on the invalid operand usage (including out of range > >> constants). It adds new tests with proper constants, testing the > >> extremes of valid values. > >> > >> OK for the trunk, or should we remove the D03 constraint? > > > > Reviewed-by: Christoph Muellner > > > > The patch does not apply cleanly anymore, because there were some > > small changes in crypto.md. > Here's an update to that old patch that also takes care of the pattern > where we allow 0..10 inclusive, but not registers. > > Regression tested on rv64gc without new failures. It'll need a > ChangeLog when approved, but that's easy to adjust. Looks good and tests pass for rv64gc and rv32gc. Reviewed-by: Christoph Muellner Tested-by: Christoph Muellner
Re: [PATCH v4] RISC-V: Change csr_operand into vector_length_operand for vsetvl patterns.
On Tue, Jan 2, 2024 at 2:35 AM juzhe.zh...@rivai.ai wrote: > > LGTM assume you have passed the regression. Committed. I've rebased this patch, validated that there are no regressions with the patch, and reworded the commit message a bit before that. > > > > juzhe.zh...@rivai.ai > > > From: Jun Sha (Joshua) > Date: 2023-12-29 12:10 > To: gcc-patches > CC: jim.wilson.gcc; palmer; andrew; philipp.tomsich; jeffreyalaw; > christoph.muellner; juzhe.zhong; Jun Sha (Joshua); Jin Ma; Xianmiao Qu > Subject: [PATCH v4] RISC-V: Change csr_operand into vector_length_operand for > vsetvl patterns. > This patch use vector_length_operand instead of csr_operand for > vsetvl patterns, so that changes for vector will not affect scalar > patterns using csr_operand in riscv.md. > > gcc/ChangeLog: > > * config/riscv/vector.md: > Use vector_length_operand for vsetvl patterns. > > Co-authored-by: Jin Ma > Co-authored-by: Xianmiao Qu > Co-authored-by: Christoph Müllner > --- > gcc/config/riscv/vector.md | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md > index f607d768b26..b5a9055cdc4 100644 > --- a/gcc/config/riscv/vector.md > +++ b/gcc/config/riscv/vector.md > @@ -1496,7 +1496,7 @@ > (define_insn "@vsetvl" >[(set (match_operand:P 0 "register_operand" "=r") > - (unspec:P [(match_operand:P 1 "csr_operand" "rK") > + (unspec:P [(match_operand:P 1 "vector_length_operand" "rK") >(match_operand 2 "const_int_operand" "i") >(match_operand 3 "const_int_operand" "i") >(match_operand 4 "const_int_operand" "i") > @@ -1542,7 +1542,7 @@ > ;; in vsetvl instruction pattern. > (define_insn "@vsetvl_discard_result" >[(set (reg:SI VL_REGNUM) > - (unspec:SI [(match_operand:P 0 "csr_operand" "rK") > + (unspec:SI [(match_operand:P 0 "vector_length_operand" "rK") > (match_operand 1 "const_int_operand" "i") > (match_operand 2 "const_int_operand" "i")] UNSPEC_VSETVL)) > (set (reg:SI VTYPE_REGNUM) > @@ -1564,7 +1564,7 @@ > ;; such pattern can allow us gain benefits of these optimizations. > (define_insn_and_split "@vsetvl_no_side_effects" >[(set (match_operand:P 0 "register_operand" "=r") > - (unspec:P [(match_operand:P 1 "csr_operand" "rK") > + (unspec:P [(match_operand:P 1 "vector_length_operand" "rK") >(match_operand 2 "const_int_operand" "i") >(match_operand 3 "const_int_operand" "i") >(match_operand 4 "const_int_operand" "i") > @@ -1608,7 +1608,7 @@ >[(set (match_operand:DI 0 "register_operand") > (sign_extend:DI >(subreg:SI > - (unspec:DI [(match_operand:P 1 "csr_operand") > + (unspec:DI [(match_operand:P 1 "vector_length_operand") > (match_operand 2 "const_int_operand") > (match_operand 3 "const_int_operand") > (match_operand 4 "const_int_operand") > -- > 2.17.1 > >
Re: Re: [PATCH v4] RISC-V: Adds the prefix "th." for the instructions of XTheadVector.
On Thu, Jan 4, 2024 at 10:18 AM juzhe.zh...@rivai.ai
wrote:
>
> \ No newline at end of file
>
> Each file needs newline.
>
> I am not able to review arch stuff. This needs kito.
>
> Besides, Andrew Pinski want us defer theadvector to GCC-15.
Maybe I misread this (sorry if so), but I though that was answered by Kito here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641723.html
>
> I have no strong opinion here.
>
>
> juzhe.zh...@rivai.ai
>
>
> 发件人： joshua
> 发送时间： 2024-01-04 17:15
> 收件人： 钟居哲; Jeff Law; gcc-patches
> 抄送： jim.wilson.gcc; palmer; andrew; philipp.tomsich; Christoph Müllner;
> jinma; Cooper Qu
> 主题： Re：Re: [PATCH v4] RISC-V: Adds the prefix "th." for the instructions of
> XTheadVector.
> Hi Juzhe,
>
> So is the following patch that this patch relies on OK to commit?
> https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641533.html
>
> Joshua
>
>
>
>
> --
> 发件人：钟居哲
> 发送时间：2024年1月2日(星期二) 06:57
> 收件人：Jeff Law;
> "cooper.joshua";
> "gcc-patches"
> 抄 送："jim.wilson.gcc"; palmer;
> andrew; "philipp.tomsich";
> "Christoph Müllner";
> jinma; Cooper Qu
> 主 题：Re: Re: [PATCH v4] RISC-V: Adds the prefix "th." for the instructions of
> XTheadVector.
>
>
> This is Ok from my side.
> But before commit this patch, I think we need this patch first:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641533.html
>
>
> I will be back to work so I will take a look at other patches today.
> juzhe.zh...@rivai.ai
>
>
> From: Jeff Law
> Date: 2024-01-01 01:43
> To: Jun Sha (Joshua); gcc-patches
> CC: jim.wilson.gcc; palmer; andrew; philipp.tomsich; christoph.muellner;
> juzhe.zhong; Jin Ma; Xianmiao Qu
> Subject: Re: [PATCH v4] RISC-V: Adds the prefix "th." for the instructions of
> XTheadVector.
>
>
>
> On 12/28/23 21:19, Jun Sha (Joshua) wrote:
> > This patch adds th. prefix to all XTheadVector instructions by
> > implementing new assembly output functions. We only check the
> > prefix is 'v', so that no extra attribute is needed.
> >
> > gcc/ChangeLog:
> >
> > * config/riscv/riscv-protos.h (riscv_asm_output_opcode):
> > New function to add assembler insn code prefix/suffix.
> > * config/riscv/riscv.cc (riscv_asm_output_opcode): Likewise.
> > * config/riscv/riscv.h (ASM_OUTPUT_OPCODE): Likewise.
> >
> > Co-authored-by: Jin Ma
> > Co-authored-by: Xianmiao Qu
> > Co-authored-by: Christoph Müllner
> > ---
> > gcc/config/riscv/riscv-protos.h| 1 +
> > gcc/config/riscv/riscv.cc | 14 ++
> > gcc/config/riscv/riscv.h | 4
> > .../gcc.target/riscv/rvv/xtheadvector/prefix.c | 12
> > 4 files changed, 31 insertions(+)
> > create mode 100644
> > gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/prefix.c
> >
> > diff --git a/gcc/config/riscv/riscv-protos.h
> > b/gcc/config/riscv/riscv-protos.h
> > index 31049ef7523..5ea54b45703 100644
> > --- a/gcc/config/riscv/riscv-protos.h
> > +++ b/gcc/config/riscv/riscv-protos.h
> > @@ -102,6 +102,7 @@ struct riscv_address_info {
> > };
> >
> > /* Routines implemented in riscv.cc. */
> > +extern const char *riscv_asm_output_opcode (FILE *asm_out_file, const char
> > *p);
> > extern enum riscv_symbol_type riscv_classify_symbolic_expression (rtx);
> > extern bool riscv_symbolic_constant_p (rtx, enum riscv_symbol_type *);
> > extern int riscv_float_const_rtx_index_for_fli (rtx);
> > diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> > index 0d1cbc5cb5f..ea1d59d9cf2 100644
> > --- a/gcc/config/riscv/riscv.cc
> > +++ b/gcc/config/riscv/riscv.cc
> > @@ -5636,6 +5636,20 @@ riscv_get_v_regno_alignment (machine_mode mode)
> > return lmul;
> > }
> >
> > +/* Define ASM_OUTPUT_OPCODE to do anything special before
> > + emitting an opcode. */
> > +const char *
> > +riscv_asm_output_opcode (FILE *asm_out_file, const char *p)
> > +{
> > + /* We need to add th. prefix to all the xtheadvector
> > + insturctions here.*/
> > + if (TARGET_XTHEADVECTOR && current_output_insn != NULL_RTX &&
> > + p[0] == 'v')
> > +fputs ("th.", asm_out_file);
> > +
> > + return p;
> Just a formatting nit. The GNU standards break lines before the
> operator, not after. So
>if (TARGET_XTHEADVECTOR
>&& current_output_insn != NULL
>&& p[0] == 'v')
>
> Note that current_output_insn is "extern rtx_insn *", so use NULL, not
> NULL_RTX.
>
> Neither of these nits require a new version for review. Just fix them.
>
> If Juzhe is fine with this, so am I. We can refine it if necessary later.
>
> jeff
>
>
>
Re: [PATCH V3 0/3] RISC-V: Add intrinsics for Bitmanip and Scalar Crypto extensions
The tests still fail. gcc: Unexpected fails for rv64gc lp64d medlow FAIL: gcc.target/riscv/scalar_bitmanip_intrinsic-32.c -O0 (test for excess errors) FAIL: gcc.target/riscv/scalar_bitmanip_intrinsic-32.c -O1 (test for excess errors) FAIL: gcc.target/riscv/scalar_bitmanip_intrinsic-32.c -O2 (test for excess errors) FAIL: gcc.target/riscv/scalar_bitmanip_intrinsic-32.c -Os (test for excess errors) FAIL: gcc.target/riscv/scalar_bitmanip_intrinsic-32.c -Oz (test for excess errors) FAIL: gcc.target/riscv/scalar_crypto_intrinsic-32.c -O0 (test for excess errors) FAIL: gcc.target/riscv/scalar_crypto_intrinsic-32.c -O1 (test for excess errors) FAIL: gcc.target/riscv/scalar_crypto_intrinsic-32.c -O2 (test for excess errors) FAIL: gcc.target/riscv/scalar_crypto_intrinsic-32.c -Os (test for excess errors) FAIL: gcc.target/riscv/scalar_crypto_intrinsic-32.c -Oz (test for excess errors) FAIL: gcc.target/riscv/scalar_crypto_intrinsic-64.c -O0 (test for excess errors) FAIL: gcc.target/riscv/scalar_crypto_intrinsic-64.c -O1 (test for excess errors) FAIL: gcc.target/riscv/scalar_crypto_intrinsic-64.c -O2 (test for excess errors) FAIL: gcc.target/riscv/scalar_crypto_intrinsic-64.c -Os (test for excess errors) FAIL: gcc.target/riscv/scalar_crypto_intrinsic-64.c -Oz (test for excess errors) Note, this is not only a rv32/rv64 issue, because also -64.c tests fail. gcc: Unexpected fails for rv32gc ilp32d medlow FAIL: gcc.target/riscv/scalar_bitmanip_intrinsic-64-emulated.c -O1 (test for excess errors) FAIL: gcc.target/riscv/scalar_bitmanip_intrinsic-64-emulated.c -O2 (test for excess errors) FAIL: gcc.target/riscv/scalar_bitmanip_intrinsic-64-emulated.c -Os (test for excess errors) FAIL: gcc.target/riscv/scalar_bitmanip_intrinsic-64-emulated.c -Oz (test for excess errors) FAIL: gcc.target/riscv/scalar_bitmanip_intrinsic-64.c -O0 (test for excess errors) FAIL: gcc.target/riscv/scalar_bitmanip_intrinsic-64.c -O1 (test for excess errors) FAIL: gcc.target/riscv/scalar_bitmanip_intrinsic-64.c -O2 (test for excess errors) FAIL: gcc.target/riscv/scalar_bitmanip_intrinsic-64.c -Os (test for excess errors) FAIL: gcc.target/riscv/scalar_bitmanip_intrinsic-64.c -Oz (test for excess errors) FAIL: gcc.target/riscv/scalar_crypto_intrinsic-64.c -O0 (test for excess errors) FAIL: gcc.target/riscv/scalar_crypto_intrinsic-64.c -O1 (test for excess errors) FAIL: gcc.target/riscv/scalar_crypto_intrinsic-64.c -O2 (test for excess errors) FAIL: gcc.target/riscv/scalar_crypto_intrinsic-64.c -Os (test for excess errors) FAIL: gcc.target/riscv/scalar_crypto_intrinsic-64.c -Oz (test for excess errors) On Tue, Dec 26, 2023 at 6:47 AM Liao Shihua wrote: > > Update v2 -> v3: > 1. Change pattern mode form X to GPR in orcb, clmul, and brev8. > 2. Add emulated testsuite. > 3. Removed duplicate testsuite between built-in and intrinsic. > 4. Typo fix. > > Update v1 -> v2: > 1. Rename *_intrinsic-* to *_intrinsic-XLEN. > 2. Typo fix. > 3. Intrinsics with immediate arguments will use marcos at O0 . > > It's a little patch add just provides a mapping from the RV intrinsics to the > builtin > names within GCC. > > Liao Shihua (3): > RISC-V: Remove the Scalar Bitmanip and Crypto Built-In function > testsuites > RISC-V: Add C intrinsic for Scalar Crypto Extension > RISC-V: Add C intrinsic for Scalar Bitmanip Extension > > gcc/config.gcc| 2 +- > gcc/config/riscv/bitmanip.md | 10 +- > gcc/config/riscv/crypto.md| 4 +- > gcc/config/riscv/riscv-builtins.cc| 22 ++ > gcc/config/riscv/riscv-cmo.def| 12 +- > gcc/config/riscv/riscv-ftypes.def | 2 + > gcc/config/riscv/riscv-scalar-crypto.def | 22 +- > gcc/config/riscv/riscv_bitmanip.h | 297 + > gcc/config/riscv/riscv_crypto.h | 309 ++ > .../riscv/scalar_bitmanip_intrinsic-32.c | 96 ++ > .../scalar_bitmanip_intrinsic-64-emulated.c | 32 ++ > .../riscv/scalar_bitmanip_intrinsic-64.c | 114 +++ > .../riscv/scalar_crypto_intrinsic-32.c| 114 +++ > .../riscv/scalar_crypto_intrinsic-64.c| 122 +++ > gcc/testsuite/gcc.target/riscv/zbbw.c | 26 -- > gcc/testsuite/gcc.target/riscv/zbc32.c| 23 -- > gcc/testsuite/gcc.target/riscv/zbc64.c| 23 -- > gcc/testsuite/gcc.target/riscv/zbkb32.c | 18 - > gcc/testsuite/gcc.target/riscv/zbkb64.c | 5 - > gcc/testsuite/gcc.target/riscv/zbkc32.c | 17 - > gcc/testsuite/gcc.target/riscv/zbkc64.c | 17 - > gcc/testsuite/gcc.target/riscv/zbkx32.c | 18 - > gcc/testsuite/gcc.target/riscv/zbkx64.c | 18 - > gcc/testsuite/gcc.target/riscv/zknd32-2.c | 28 -- > gcc/testsuite/gcc.target/riscv/zknd64-2.c | 42 --- > gcc/testsuite/gcc.target/riscv/zkne32-2.c | 28 -- > gcc/testsuite/
[PATCH] RISC-V: Document optimization parameter riscv-strcmp-inline-limit
This patch documents the optimization parameter
riscv-strcmp-inline-limit, which can be used to tweak the behaviour
of -minline-strcmp and -minline-strncmp.
gcc/ChangeLog:
PR target/112650
* doc/invoke.texi: Document riscv-strcmp-inline-limit.
Signed-off-by: Christoph Müllner
---
gcc/doc/invoke.texi | 8
1 file changed, 8 insertions(+)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 2fab4c5d71f..ba2d843b484 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -29846,6 +29846,10 @@ Inlining will only be done if the strings are properly
aligned
and instructions for accelerated processing are available.
The default is to not inline strcmp calls.
+The @option{--param riscv-strcmp-inline-limit=@{n}} parameter controls
+the maximum number of bytes compared by the inlined code.
+The default value is 64.
+
@opindex minline-strncmp
@item -minline-strncmp
@itemx -mno-inline-strncmp
@@ -29854,6 +29858,10 @@ Inlining will only be done if the strings are properly
aligned
and instructions for accelerated processing are available.
The default is to not inline strncmp calls.
+The @option{--param riscv-strcmp-inline-limit=@{n}} parameter controls
+the maximum number of bytes compared by the inlined code.
+The default value is 64.
+
@opindex mshorten-memrefs
@item -mshorten-memrefs
@itemx -mno-shorten-memrefs
--
2.41.0
Re: [PATCH] RISC-V: Check if zcd conflicts with zcmt and zcmp
On Mon, Dec 4, 2023 at 8:48 AM Kito Cheng wrote:
LGTM
I've double-checked this in the Zc-1.0.4-3.pdf:
* Zcmp is incompatible with Zcd
* Zcmp depends on Zca
* Zcmt is incompatible with Zcd
* Zcmt depends on Zca and Zicsr
The implies-relations are already implemented.
This patch enforces the incompatibility-relations.
>
> gcc/ChangeLog:
>
> * common/config/riscv/riscv-common.cc
> (riscv_subset_list::check_conflict_ext): Check and conflicts
> with zcmt and zcmp.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/arch-29.c: New test.
> * gcc.target/riscv/arch-30.c: New test.
> ---
> gcc/common/config/riscv/riscv-common.cc | 8
> gcc/testsuite/gcc.target/riscv/arch-29.c | 7 +++
> gcc/testsuite/gcc.target/riscv/arch-30.c | 7 +++
> 3 files changed, 22 insertions(+)
> create mode 100644 gcc/testsuite/gcc.target/riscv/arch-29.c
> create mode 100644 gcc/testsuite/gcc.target/riscv/arch-30.c
>
> diff --git a/gcc/common/config/riscv/riscv-common.cc
> b/gcc/common/config/riscv/riscv-common.cc
> index aecb342b164..bfb41827f7a 100644
> --- a/gcc/common/config/riscv/riscv-common.cc
> +++ b/gcc/common/config/riscv/riscv-common.cc
> @@ -1230,6 +1230,14 @@ riscv_subset_list::check_conflict_ext ()
>/* 'H' hypervisor extension requires base ISA with 32 registers. */
>if (lookup ("e") && lookup ("h"))
> error_at (m_loc, "%<-march=%s%>: h extension requires i extension",
> m_arch);
> +
> + if (lookup ("zcd"))
> +{
> + if (lookup ("zcmt"))
> + error_at (m_loc, "%<-march=%s%>: zcd conflicts with zcmt", m_arch);
> + if (lookup ("zcmp"))
> + error_at (m_loc, "%<-march=%s%>: zcd conflicts with zcmp", m_arch);
> +}
> }
>
> /* Parsing function for multi-letter extensions.
> diff --git a/gcc/testsuite/gcc.target/riscv/arch-29.c
> b/gcc/testsuite/gcc.target/riscv/arch-29.c
> new file mode 100644
> index 000..f8281275878
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/arch-29.c
> @@ -0,0 +1,7 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=rv64id_zcd_zcmt -mabi=lp64d" } */
> +int foo()
> +{
> +}
> +
> +/* { dg-error "zcd conflicts with zcmt" "" { target *-*-* } 0 } */
> diff --git a/gcc/testsuite/gcc.target/riscv/arch-30.c
> b/gcc/testsuite/gcc.target/riscv/arch-30.c
> new file mode 100644
> index 000..3e67ea0bb06
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/arch-30.c
> @@ -0,0 +1,7 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=rv64id_zcd_zcmp -mabi=lp64d" } */
> +int foo()
> +{
> +}
> +
> +/* { dg-error "zcd conflicts with zcmp" "" { target *-*-* } 0 } */
> --
> 2.40.1
>
[PATCH v2] RISC-V: Document optimization parameter riscv-strcmp-inline-limit
This patch documents the optimization parameter
riscv-strcmp-inline-limit, which can be used to tweak the behaviour
of -minline-strcmp and -minline-strncmp.
gcc/ChangeLog:
PR target/112650
* doc/invoke.texi: Document riscv-strcmp-inline-limit.
Signed-off-by: Christoph Müllner
---
gcc/doc/invoke.texi | 8
1 file changed, 8 insertions(+)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 6fe63b5f999..2b51ff304f6 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -29846,6 +29846,10 @@ Inlining will only be done if the strings are properly
aligned
and instructions for accelerated processing are available.
The default is to not inline strcmp calls.
+The @option{--param riscv-strcmp-inline-limit=@var{n}} parameter controls
+the maximum number of bytes compared by the inlined code.
+The default value is 64.
+
@opindex minline-strncmp
@item -minline-strncmp
@itemx -mno-inline-strncmp
@@ -29854,6 +29858,10 @@ Inlining will only be done if the strings are properly
aligned
and instructions for accelerated processing are available.
The default is to not inline strncmp calls.
+The @option{--param riscv-strcmp-inline-limit=@var{n}} parameter controls
+the maximum number of bytes compared by the inlined code.
+The default value is 64.
+
@opindex mshorten-memrefs
@item -mshorten-memrefs
@itemx -mno-shorten-memrefs
--
2.43.0
Re: [PATCH] RISC-V: Document optimization parameter riscv-strcmp-inline-limit
On Mon, Dec 4, 2023 at 4:46 AM Kito Cheng wrote:
>
> Wait, I got this on my machine?
>
> ../../../../riscv-gnu-toolchain-trunk/gcc/gcc/doc/invoke.texi:29774:
> misplaced }
> ../../../../riscv-gnu-toolchain-trunk/gcc/gcc/doc/invoke.texi:29786:
> misplaced }
@{n} should be @var{n}.
I was too optimistic and sent the patch before the build finished (or
in this case failed).
Sorry for that.
I have sent a v2 that builds fine:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639142.html
>
>
> On Mon, Dec 4, 2023 at 10:43 AM Kito Cheng wrote:
> >
> > LGTM
> >
> > On Sun, Dec 3, 2023 at 5:16 AM Christoph Müllner
> > wrote:
> >>
> >> This patch documents the optimization parameter
> >> riscv-strcmp-inline-limit, which can be used to tweak the behaviour
> >> of -minline-strcmp and -minline-strncmp.
> >>
> >> gcc/ChangeLog:
> >>
> >> PR target/112650
> >> * doc/invoke.texi: Document riscv-strcmp-inline-limit.
> >>
> >> Signed-off-by: Christoph Müllner
> >> ---
> >> gcc/doc/invoke.texi | 8
> >> 1 file changed, 8 insertions(+)
> >>
> >> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> >> index 2fab4c5d71f..ba2d843b484 100644
> >> --- a/gcc/doc/invoke.texi
> >> +++ b/gcc/doc/invoke.texi
> >> @@ -29846,6 +29846,10 @@ Inlining will only be done if the strings are
> >> properly aligned
> >> and instructions for accelerated processing are available.
> >> The default is to not inline strcmp calls.
> >>
> >> +The @option{--param riscv-strcmp-inline-limit=@{n}} parameter controls
> >> +the maximum number of bytes compared by the inlined code.
> >> +The default value is 64.
> >> +
> >> @opindex minline-strncmp
> >> @item -minline-strncmp
> >> @itemx -mno-inline-strncmp
> >> @@ -29854,6 +29858,10 @@ Inlining will only be done if the strings are
> >> properly aligned
> >> and instructions for accelerated processing are available.
> >> The default is to not inline strncmp calls.
> >>
> >> +The @option{--param riscv-strcmp-inline-limit=@{n}} parameter controls
> >> +the maximum number of bytes compared by the inlined code.
> >> +The default value is 64.
> >> +
> >> @opindex mshorten-memrefs
> >> @item -mshorten-memrefs
> >> @itemx -mno-shorten-memrefs
> >> --
> >> 2.41.0
> >>
Re: [PATCH 0/2] RISC-V: Add intrinsics for Bitmanip and Scalar Crypto extensions.
On Tue, Dec 5, 2023 at 1:05 PM Liao Shihua wrote:
>
>
> It's a little patch add just provides a mapping from the RV intrinsic to the
> builtin
> names within GCC.
Thanks for working on this!
I checked with ./contrib/check_GNU_style, which found a two issues:
* Trailing whitespace (most likely caused by the CRLF line terminators)
* There should be exactly one space between function name and parenthesis.
Also, I don't like so much the fact that the comments in the "#endif"
lines don't match the "#if".
E.g., we have "#if defined(__riscv_zksed)" and "#endif // ZKSED".
I would expect that, in this case, we have "#endif // __riscv_zksed".
In my comments for v1 I asked about the reasons for using macros vs
inline-functions.
Craig Topper answered this by clarifying that immediate won't be
propagated in case of -O0,
because inlining will be disabled (can be tested via __OPTIMIZE__).
He also linked to existing code that shows how this is handled in existing code:
https://github.com/gcc-mirror/gcc/blob/master/gcc/config/i386/xmmintrin.h#L52
We should follow this pattern for intrinsics that have immediate
arguments (others are fine):
#ifdef __OPTIMIZE__
// inline function
#else
// macro
#endif
Regarding the tests, I think the dg-skip-if for "-g" and "-flto" is fine.
But the dg-options lines seem to be too restrictive (e.g. "-O0" is skipped).
The following should be enough for RV64 tests:
/* { dg-options "-march=rv64gc_zknd_zkne_zknh_zksed_zksh -mabi=lp64" } */
Nit: I don't mind if we have a "-32" and a "-64" test file, but I
would rename them
accordingly ("-1.c" -> "-32.c" and "-2.c" -> "-64.c").
Alternatively, if you prefer to merge both files into one, this can be
done using
the following dg-options in one file:
/* { dg-options "-march=rv64gc_zknd_zkne_zknh_zksed_zksh" { target {
rv64 } } } */
/* { dg-options "-march=rv32gc_zknd_zkne_zknh_zksed_zksh" { target {
rv32 } } } */
The scan-assembler lines can then be adjusted with the "{ target {
rvNN } }" as well:
/* { dg-final { scan-assembler-times "aes64ds\t" 1 { target { rv64 } } } } */
And the tests can be separated for RV32/RV64 using
#if __riscv_xlen == 64
// tests for RV64 only
#else
// tests for RV32 only
#endif // __riscv_xlen == 64
BR
Christoph
>
> Liao Shihua (2):
> Add C intrinsics of Scalar Crypto Extension
> Add C intrinsics of Bitmanip Extension
>
> gcc/config.gcc| 2 +-
> gcc/config/riscv/riscv-builtins.cc| 22 ++
> gcc/config/riscv/riscv-types.def | 2 +
> gcc/config/riscv/riscv-scalar-crypto.def | 18 ++
> gcc/config/riscv/riscv_bitmanip.h | 297 ++
> gcc/config/riscv/riscv_crypto.h | 280 +
> .../riscv/scalar_bitmanip_intrinsic-1.c | 97 ++
> .../riscv/scalar_bitmanip_intrinsic-2.c | 115 +++
> .../riscv/scalar_crypto_intrinsic-1.c | 115 +++
> .../riscv/scalar_crypto_intrinsic-2.c | 122 +++
> 10 files changed, 1069 insertions(+), 1 deletion(-)
> create mode 100644 gcc/config/riscv/riscv_bitmanip.h
> create mode 100644 gcc/config/riscv/riscv_crypto.h
> create mode 100644
> gcc/testsuite/gcc.target/riscv/scalar_bitmanip_intrinsic-1.c
> create mode 100644
> gcc/testsuite/gcc.target/riscv/scalar_bitmanip_intrinsic-2.c
> create mode 100644 gcc/testsuite/gcc.target/riscv/scalar_crypto_intrinsic-1.c
> create mode 100644 gcc/testsuite/gcc.target/riscv/scalar_crypto_intrinsic-2.c
>
> --
> 2.34.1
>
[PATCH] RISC-V: xtheadfmemidx: Disable if xtheadmemidx is not available
XTheadMemIdx provides register-register offsets for GP register
loads/stores. XTheadFMemIdx does the same for FP registers.
We've observed an issue with XTheadFMemIdx-only builds, where FP
registers have been promoted to GP registers:
(insn 26 22 51 (set (reg:DF 15 a5 [orig:136 ] [136])
(mem/u:DF (plus:DI (reg/f:DI 15 a5 [141])
(reg:DI 10 a0 [144])) [1 CSWTCH.2[_10]+0 S8 A64])) 217
{*movdf_hardfloat_rv64}
(expr_list:REG_DEAD (reg:DI 10 a0 [144])
(nil)))
This results in the following assembler error:
Assembler messages:
Error: unrecognized opcode `th.lrd a5,a5,a0,0', extension `xtheadmemidx'
required
There seems to be a (reasonable) assumption, that addressing modes
for FP registers are compatible with those of GP registers.
We already ran into a similar issue during development of the
XTheadFMemIdx support patch, where we could trace the issue down to
the optimization splitters. Back then we simply disabled them in case
XTheadMemIdx is not available. But as it turned out, that was not
enough.
To ensure, we won't see such issues anymore, let's make the support
for XTheadFMemIdx depend on XTheadMemIdx. I.e., if only XTheadFMemIdx
is available, then no instructions of this extension will be emitted.
While this looks a bit drastic at first view, it is the best practical
solution since XTheadFMemIdx without XTheadMemIdx does not exist in real
hardware and would be an odd thing to do.
gcc/ChangeLog:
* config/riscv/thead.cc (th_memidx_classify_address_index):
Require TARGET_XTHEADMEMIDX for FP modes.
* config/riscv/thead.md: Require TARGET_XTHEADMEMIDX for all
XTheadFMemIdx pattern.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/xtheadfmemidx-without-xtheadmemidx.c: New test.
Reported-by: Jin Ma
Signed-off-by: Christoph Müllner
---
gcc/config/riscv/thead.cc | 3 +-
gcc/config/riscv/thead.md | 19 -
.../xtheadfmemidx-without-xtheadmemidx.c | 39 +++
3 files changed, 51 insertions(+), 10 deletions(-)
create mode 100644
gcc/testsuite/gcc.target/riscv/xtheadfmemidx-without-xtheadmemidx.c
diff --git a/gcc/config/riscv/thead.cc b/gcc/config/riscv/thead.cc
index bd9af7ecd60..20353995931 100644
--- a/gcc/config/riscv/thead.cc
+++ b/gcc/config/riscv/thead.cc
@@ -603,7 +603,8 @@ th_memidx_classify_address_index (struct riscv_address_info
*info, rtx x,
{
/* Ensure that the mode is supported. */
if (!(TARGET_XTHEADMEMIDX && is_memidx_mode (mode))
- && !(TARGET_XTHEADFMEMIDX && is_fmemidx_mode (mode)))
+ && !(TARGET_XTHEADMEMIDX
+ && TARGET_XTHEADFMEMIDX && is_fmemidx_mode (mode)))
return false;
if (GET_CODE (x) != PLUS)
diff --git a/gcc/config/riscv/thead.md b/gcc/config/riscv/thead.md
index 2babfafb23c..186ca468875 100644
--- a/gcc/config/riscv/thead.md
+++ b/gcc/config/riscv/thead.md
@@ -822,11 +822,19 @@ (define_insn_and_split "*th_memidx_UZ_c"
)
;; XTheadFMemIdx
+;; Note, that we might get GP registers in FP-mode (reg:DF a2)
+;; which cannot be handled by the XTheadFMemIdx instructions.
+;; This might even happend after register allocation.
+;; We could implement splitters that undo the combiner results
+;; if "after_reload && !HARDFP_REG_P (operands[0])", but this
+;; raises even more questions (e.g. split into what?).
+;; So let's solve this by simply requiring XTheadMemIdx
+;; which provides the necessary instructions to cover this case.
(define_insn "*th_fmemidx_movsf_hardfloat"
[(set (match_operand:SF 0 "nonimmediate_operand" "=f,th_m_mir,f,th_m_miu")
(match_operand:SF 1 "move_operand" " th_m_mir,f,th_m_miu,f"))]
- "TARGET_HARD_FLOAT && TARGET_XTHEADFMEMIDX
+ "TARGET_HARD_FLOAT && TARGET_XTHEADFMEMIDX && TARGET_XTHEADMEMIDX
&& (register_operand (operands[0], SFmode)
|| reg_or_0_operand (operands[1], SFmode))"
{ return riscv_output_move (operands[0], operands[1]); }
@@ -837,6 +845,7 @@ (define_insn "*th_fmemidx_movdf_hardfloat_rv64"
[(set (match_operand:DF 0 "nonimmediate_operand" "=f,th_m_mir,f,th_m_miu")
(match_operand:DF 1 "move_operand" " th_m_mir,f,th_m_miu,f"))]
"TARGET_64BIT && TARGET_DOUBLE_FLOAT && TARGET_XTHEADFMEMIDX
+ && TARGET_XTHEADMEMIDX
&& (register_operand (operands[0], DFmode)
|| reg_or_0_operand (operands[1], DFmode))"
{ return riscv_output_move (operands[0], operands[1]); }
@@ -845,14 +854,6 @@ (define_insn "*th_fmemidx_movdf_hardfloat_rv64"
;; XTheadFMemIdx optimizations
;; Similar like XTheadMemIdx optimizations, but less cases.
-;; Note, that we might get GP registers in FP-mode (reg:DF a2)
-;; whic
[PATCH] RISC-V: xtheadmemidx: Document inline asm issue with memory constraint
The XTheadMemIdx support relies on the fact that memory operands that
can be expressed by XTheadMemIdx instructions, will only appear as
operands of such instructions. For internal instruction generation
this is guaranteed by the implemenation. However, in case of inline
assembly, this guarantee is not given and we cannot differentiate
these two cases when printing the operand:
asm volatile ("sd %1,%0" : "=m"(*tmp) : "r"(val));
asm volatile ("th.srd %1,%0" : "=m"(*tmp) : "r"(val));
If XTheadMemIdx is enabled, then the address will be printed as if an
XTheadMemIdx instruction is emitted, which is obviously wrong in the
first case.
There might be solutions to handle this (e.g. using TARGET_MEM_CONSTRAINT
or extending the mnemonics to accept the standard operands for
XTheadMemIdx instructions), but let's document this behavior for now
as a known issue by adding xfail tests until we have an acceptable fix.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/xtheadmemidx-inline-asm-1.c: New test.
Reported-by: Jin Ma
Signed-off-by: Christoph Müllner
---
.../riscv/xtheadmemidx-inline-asm-1.c | 26 +++
1 file changed, 26 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadmemidx-inline-asm-1.c
diff --git a/gcc/testsuite/gcc.target/riscv/xtheadmemidx-inline-asm-1.c
b/gcc/testsuite/gcc.target/riscv/xtheadmemidx-inline-asm-1.c
new file mode 100644
index 000..da52433feb7
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/xtheadmemidx-inline-asm-1.c
@@ -0,0 +1,26 @@
+/* { dg-do compile } */
+/* { dg-skip-if "" { *-*-* } { "-O0" "-O1" "-Og" } } */
+/* { dg-options "-march=rv64gc_xtheadmemidx" } */
+
+/* XTheadMemIdx support is implemented such that reg+reg addressing mode
+ loads/stores are preferred over standard loads/stores.
+ If this order changed using inline assembly, the result will be invalid
+ instructions. This test serves the purpose of documenting this
+ limitation until a solution is available. */
+
+void foo (void *p, unsigned long off, unsigned long val)
+{
+ unsigned long *tmp = (unsigned long*)(p + off);
+ asm volatile ("sd%1,%0" : "=m"(*tmp) : "r"(val));
+}
+
+void bar (void *p, unsigned long off, unsigned long val)
+{
+ unsigned long *tmp = (unsigned long*)(p + off);
+ asm volatile ("th.srd%1,%0" : "=m"(*tmp) : "r"(val));
+}
+
+/* { dg-final { scan-assembler "sd\t\[a-z\]\[0-9\]+,0\\(\[a-z\]\[0-9\]+\\)" {
xfail *-*-* } } } */
+/* { dg-final { scan-assembler-not
"sd\t\[a-z\]\[0-9\]+,\[a-z\]\[0-9\]+,\[a-z\]\[0-9\]+,0" { xfail *-*-* } } } */
+/* { dg-final { scan-assembler
"th\.srd\t\[a-z\]\[0-9\]+,\[a-z\]\[0-9\]+,\[a-z\]\[0-9\]+,0" } } */
+/* { dg-final { scan-assembler-not
"th\.srd\t\[a-z\]\[0-9\]+,0\\(\[a-z\]\[0-9\]+\\)" } } */
--
2.43.0
Re: [PATCH V2 0/2] RISC-V: Add intrinsics for Bitmanip and Scalar Crypto extensions
On Thu, Dec 7, 2023 at 11:18 AM Liao Shihua wrote:
>
> In accordance with the suggestions of Christoph Müllner, the following
> amendments are made
>
> Update v1 -> v2:
> 1. Rename *_intrinsic-* to *_intrinsic-XLEN.
> 2. Typo fix.
> 3. Intrinsics with immediate arguments will use marcos at O0 .
>
> It's a little patch add just provides a mapping from the RV intrinsics to the
> builtin
> names within GCC.
Thanks for the update!
I think this patchset was not properly tested as I see the tests failing.
$ /opt/riscv-mainline/bin/riscv64-unknown-linux-gnu-gcc
-march=rv64gc_zbb_zbc_zbkb_zbkc_zbkx -mabi=lp64d
/home/cm/src/gcc/riscv-mainline/gcc/testsuite/gcc.target/riscv/scalar_bitmanip_intrinsic-64.c
In file included from
/home/cm/src/gcc/riscv-mainline/gcc/testsuite/gcc.target/riscv/scalar_bitmanip_intrinsic-64.c:5:
/opt/riscv-mainline/lib/gcc/riscv64-unknown-linux-gnu/14.0.0/include/riscv_bitmanip.h:
In function '__riscv_orc_b_32':
/opt/riscv-mainline/lib/gcc/riscv64-unknown-linux-gnu/14.0.0/include/riscv_bitmanip.h:61:10:
error: implicit declaration of function '__builtin_riscv_orc_b_32';
did you mean '__builtin_riscv_orc_b_64'?
[-Wimplicit-function-declaration]
61 | return __builtin_riscv_orc_b_32 (x);
| ^~~~
| __builtin_riscv_orc_b_64
The spec says: Emulated with rev8+sext.w on RV64.
But I think this is a bug in the spec and should be "orc.b + sext.w".
Still, you need to handle that somehow.
$ /opt/riscv-mainline/bin/riscv64-unknown-linux-gnu-gcc
-march=rv64gc_zknd_zkne_zknh_zksed_zksh -mabi=lp64 -mabi=lp64d
/home/cm/src/gcc/riscv-mainline/gcc/testsuite/gcc.target/riscv/scalar_crypto_intrinsic-64.c
/tmp/ccynQLn2.s: Assembler messages:
/tmp/ccynQLn2.s:127: Error: instruction aes64ks1i requires absolute expression
/tmp/ccynQLn2.s:593: Error: instruction sm4ed requires absolute expression
/tmp/ccynQLn2.s:633: Error: instruction sm4ks requires absolute expression
The absolute expression means that you cannot use a variable but must
use an immediate.
E.g.:
uint64_t foo4(uint64_t rs1)
{
return __riscv_aes64ks1i(rs1, 3);
}
Here the 3 will be encoded into the instruction.
There are probably more issues, but I stopped investigating after these two.
Also, there are some missing spaces to separate arguments. E.g.:
return __riscv_aes64ks1i(rs1,rnum);
...should be...
return __riscv_aes64ks1i(rs1, rnum);
Please make sure to test these patches for RV32 and RV64 before
sending a new revision.
If you run into issues that you can't resolve, then just reach out.
BR
Christoph
>
>
> Liao Shihua (2):
> Add C intrinsics of Scalar Crypto Extension
> Add C intrinsics of Bitmanip Extension
>
> gcc/config.gcc| 2 +-
> gcc/config/riscv/riscv-builtins.cc| 22 ++
> gcc/config/riscv/riscv-ftypes.def | 2 +
> gcc/config/riscv/riscv-scalar-crypto.def | 18 +
> gcc/config/riscv/riscv_bitmanip.h | 297 +
> gcc/config/riscv/riscv_crypto.h | 309 ++
> .../riscv/scalar_bitmanip_intrinsic-32.c | 97 ++
> .../riscv/scalar_bitmanip_intrinsic-64.c | 115 +++
> .../riscv/scalar_crypto_intrinsic-32.c| 115 +++
> .../riscv/scalar_crypto_intrinsic-64.c| 122 +++
> 10 files changed, 1098 insertions(+), 1 deletion(-)
> create mode 100644 gcc/config/riscv/riscv_bitmanip.h
> create mode 100644 gcc/config/riscv/riscv_crypto.h
> create mode 100644
> gcc/testsuite/gcc.target/riscv/scalar_bitmanip_intrinsic-32.c
> create mode 100644
> gcc/testsuite/gcc.target/riscv/scalar_bitmanip_intrinsic-64.c
> create mode 100644
> gcc/testsuite/gcc.target/riscv/scalar_crypto_intrinsic-32.c
> create mode 100644
> gcc/testsuite/gcc.target/riscv/scalar_crypto_intrinsic-64.c
>
> --
> 2.34.1
>
Re: [PATCH v2] RISC-V: Supports RISC-V Profiles in '-march' option.
On Tue, Dec 12, 2023 at 1:08 PM Jiawei wrote:
>
> Supports RISC-V profiles[1] in -march option.
>
> Default input set the profile is before other formal extensions.
>
> V2: Fixes some format errors and adds code comments for parse function
> Thanks for Jeff Law's review and comments.
>
> [1]https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc
>
> gcc/ChangeLog:
>
> * common/config/riscv/riscv-common.cc (struct riscv_profiles):
> New struct.
> (riscv_subset_list::parse_profiles): New function.
> (riscv_subset_list::parse): New table.
> * config/riscv/riscv-subset.h: New protype.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/arch-31.c: New test.
> * gcc.target/riscv/arch-32.c: New test.
> * gcc.target/riscv/arch-33.c: New test.
> * gcc.target/riscv/arch-34.c: New test.
For the positive tests (-31.c and -33.c) it would be great to test if
the enabled extension's test macros are set.
Something like this would do:
#if (!(defined __riscv_zicsr) || \
!(defined __riscv_...))
#error "Feature macros not defined"
#endif
Also, positive tests for RVI20U32 and RVI20U64 would be nice.
>
> ---
> gcc/common/config/riscv/riscv-common.cc | 83 +++-
> gcc/config/riscv/riscv-subset.h | 2 +
> gcc/testsuite/gcc.target/riscv/arch-31.c | 5 ++
> gcc/testsuite/gcc.target/riscv/arch-32.c | 5 ++
> gcc/testsuite/gcc.target/riscv/arch-33.c | 5 ++
> gcc/testsuite/gcc.target/riscv/arch-34.c | 7 ++
> 6 files changed, 106 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/gcc.target/riscv/arch-31.c
> create mode 100644 gcc/testsuite/gcc.target/riscv/arch-32.c
> create mode 100644 gcc/testsuite/gcc.target/riscv/arch-33.c
> create mode 100644 gcc/testsuite/gcc.target/riscv/arch-34.c
>
> diff --git a/gcc/common/config/riscv/riscv-common.cc
> b/gcc/common/config/riscv/riscv-common.cc
> index 4d5a2f874a2..8b674a4a280 100644
> --- a/gcc/common/config/riscv/riscv-common.cc
> +++ b/gcc/common/config/riscv/riscv-common.cc
> @@ -195,6 +195,12 @@ struct riscv_ext_version
>int minor_version;
> };
>
> +struct riscv_profiles
> +{
> + const char *profile_name;
> + const char *profile_string;
> +};
> +
> /* All standard extensions defined in all supported ISA spec. */
> static const struct riscv_ext_version riscv_ext_version_table[] =
> {
> @@ -379,6 +385,42 @@ static const struct riscv_ext_version
> riscv_combine_info[] =
>{NULL, ISA_SPEC_CLASS_NONE, 0, 0}
> };
>
> +/* This table records the mapping form RISC-V Profiles into march string. */
> +static const riscv_profiles riscv_profiles_table[] =
> +{
> + /* RVI20U only contains the base extesnion 'i' as mandatory extension. */
> + {"RVI20U64", "rv64i"},
> + {"RVI20U32", "rv32i"},
> +
> + /* RVA20U contains the 'i,m,a,f,d,c,zicsr' as mandatory extensions.
> + Currently we don't have zicntr,ziccif,ziccrse,ziccamoa,
> + zicclsm,za128rs yet. */
> + {"RVA20U64", "rv64imafdc_zicsr"},
> +
> + /* RVA20S64 mandatory include all the extensions in RVA20U64 and
> + additonal 'zifencei' as mandatory extensions.
> + Notes that ss1p11, svbare, sv39, svade, sscptr, ssvecd, sstvala should
> + control by binutils. */
> + {"RVA20S64", "rv64imafdc_zicsr_zifencei"},
> +
> + /* RVA22U contains the 'i,m,a,f,d,c,zicsr,zihintpause,zba,zbb,zbs,
> + zicbom,zicbop,zicboz,zfhmin,zkt' as mandatory extensions.
> + Currently we don't have zicntr,zihpm,ziccif,ziccrse,ziccamoa,
> + zicclsm,zic64b,za64rs yet. */
I would prefer that we implement the missing extensions that start
with 'z' as "dummy" extensions.
I.e., they (currently?) don't affect code generation, but they will be
passed on to the assembler and
will become part of the Tag_RISCV_arch string.
I admit that such "dummy" extensions may not be preferred by
maintainers, but we already
have precedence with Zkt.
I consider an incomplete expansion of a profile as misleading.
And later changes to complete the expansion could be called out as
"breaking changes".
> + {"RVA22U64", "rv64imafdc_zicsr_zihintpause_zba_zbb_zbs"
> \
> + "_zicbom_zicbop_zicboz_zfhmin_zkt"},
> +
> + /* RVA22S64 mandatory include all the extensions in RVA22U64 and
> + additonal 'zifencei,svpbmt,svinval' as mandatory extensions.
> + Notes that ss1p12, svbare, sv39, svade, sscptr, ssvecd, sstvala,
> + scounterenw extentions should control by binutils. */
Typo: extentions -> extensions
I want to challenge the implementation of RVA22S64 support
(or in general all S-mode and M-mode profile support) in toolchains:
* Adding 's*'/'m*' extensions as dummy extensions won't have much use
* Having an incomplete extension is misleading (see above)
* I doubt that RVA22S64 would find many users
Therefore, I would not add support for S-mode and M-mode profiles.
> + {"RVA22S64","rv64imafdc_zicsr_zifencei_zihintpause"
> \
> + "_zb
Re: [PATCH] RISC-V: fix scalar crypto pattern
On Wed, Dec 13, 2023 at 9:22 AM Liao Shihua wrote: > > In Scalar Crypto Built-In functions, some require immediate parameters, > But register_operand are incorrectly used in the pattern. > > E.g.: >__builtin_riscv_aes64ks1i(rs1,1) >Before: > li a5,1 > aes64ks1i a0,a0,a5 > > Assembler messages: > Error: instruction aes64ks1i requires absolute expression > >After: > aes64ks1i a0,a0,1 Looks good to me (also tested with rv32 and rv64). (I was actually surprised that the D03 constraint was not sufficient) Reviewed-by: Christoph Muellner Tested-by: Christoph Muellner Nit: I would prefer to separate arguments with a comma followed by a space. Even if the existing code was not written like that. E.g. __builtin_riscv_sm4ed(rs1,rs2,1); -> __builtin_riscv_sm4ed(rs1, rs2, 1); I propose to remove the builtin tests for scalar crypto and scalar bitmanip as part of the patchset that adds the intrinsic tests (no value in duplicated tests). > gcc/ChangeLog: > > * config/riscv/crypto.md: Use immediate_operand instead of > register_operand. > > gcc/testsuite/ChangeLog: > > * gcc.target/riscv/zknd32.c: Use immediate instead of parameter. > * gcc.target/riscv/zknd64.c: Ditto. > * gcc.target/riscv/zkne32.c: Ditto. > * gcc.target/riscv/zkne64.c: Ditto. > * gcc.target/riscv/zksed32.c: Ditto. > * gcc.target/riscv/zksed64.c: Ditto. > > --- > gcc/config/riscv/crypto.md | 16 > gcc/testsuite/gcc.target/riscv/zknd32.c | 8 > gcc/testsuite/gcc.target/riscv/zknd64.c | 4 ++-- > gcc/testsuite/gcc.target/riscv/zkne32.c | 8 > gcc/testsuite/gcc.target/riscv/zkne64.c | 4 ++-- > gcc/testsuite/gcc.target/riscv/zksed32.c | 8 > gcc/testsuite/gcc.target/riscv/zksed64.c | 8 > 7 files changed, 28 insertions(+), 28 deletions(-) > > diff --git a/gcc/config/riscv/crypto.md b/gcc/config/riscv/crypto.md > index 03a1d03397d..c45f12e421f 100644 > --- a/gcc/config/riscv/crypto.md > +++ b/gcc/config/riscv/crypto.md > @@ -148,7 +148,7 @@ >[(set (match_operand:SI 0 "register_operand" "=r") > (unspec:SI [(match_operand:SI 1 "register_operand" "r") > (match_operand:SI 2 "register_operand" "r") > - (match_operand:SI 3 "register_operand" "D03")] > + (match_operand:SI 3 "immediate_operand" "D03")] > UNSPEC_AES_DSI))] >"TARGET_ZKND && !TARGET_64BIT" >"aes32dsi\t%0,%1,%2,%3" > @@ -158,7 +158,7 @@ >[(set (match_operand:SI 0 "register_operand" "=r") > (unspec:SI [(match_operand:SI 1 "register_operand" "r") > (match_operand:SI 2 "register_operand" "r") > - (match_operand:SI 3 "register_operand" "D03")] > + (match_operand:SI 3 "immediate_operand" "D03")] > UNSPEC_AES_DSMI))] >"TARGET_ZKND && !TARGET_64BIT" >"aes32dsmi\t%0,%1,%2,%3" > @@ -193,7 +193,7 @@ > (define_insn "riscv_aes64ks1i" >[(set (match_operand:DI 0 "register_operand" "=r") > (unspec:DI [(match_operand:DI 1 "register_operand" "r") > - (match_operand:SI 2 "register_operand" "DsA")] > + (match_operand:SI 2 "immediate_operand" "DsA")] > UNSPEC_AES_KS1I))] >"(TARGET_ZKND || TARGET_ZKNE) && TARGET_64BIT" >"aes64ks1i\t%0,%1,%2" > @@ -214,7 +214,7 @@ >[(set (match_operand:SI 0 "register_operand" "=r") > (unspec:SI [(match_operand:SI 1 "register_operand" "r") > (match_operand:SI 2 "register_operand" "r") > - (match_operand:SI 3 "register_operand" "D03")] > + (match_operand:SI 3 "immediate_operand" "D03")] > UNSPEC_AES_ESI))] >"TARGET_ZKNE && !TARGET_64BIT" >"aes32esi\t%0,%1,%2,%3" > @@ -224,7 +224,7 @@ >[(set (match_operand:SI 0 "register_operand" "=r") > (unspec:SI [(match_operand:SI 1 "register_operand" "r") > (match_operand:SI 2 "register_operand" "r") > - (match_operand:SI 3 "register_operand" "D03")] > + (match_operand:SI 3 "immediate_operand" "D03")] > UNSPEC_AES_ESMI))] >"TARGET_ZKNE && !TARGET_64BIT" >"aes32esmi\t%0,%1,%2,%3" > @@ -431,7 +431,7 @@ >[(set (match_operand:SI 0 "register_operand" "=r") > (unspec:SI [(match_operand:SI 1 "register_operand" "r") > (match_operand:SI 2 "register_operand" "r") > - (match_operand:SI 3 "register_operand" "D03")] > + (match_operand:SI 3 "immediate_operand" "D03")] > SM4_OP))] >"TARGET_ZKSED && !TARGET_64BIT" >"\t%0,%1,%2,%3" > @@ -442,7 +442,7 @@ > (sign_extend:DI > (unspec:SI [(match_operand:SI 1 "register_operand" "r") > (match_operand:SI 2 "register_operand" "r") > -
Re: [PATCH v2 02/11] riscv: Restructure callee-saved register save/restore code
On Mon, Dec 19, 2022 at 10:26 AM Kito Cheng wrote:
> Something like this:
>
> static unsigned int
> riscv_next_saved_reg (unsigned int regno, unsigned int limit,
> HOST_WIDE_INT *offset, bool inc = true)
> {
> if (inc)
> regno++;
>
> while (regno <= limit)
> {
> if (BITSET_P (cfun->machine->frame.mask, regno - GP_REG_FIRST))
>{
> *offset = *offset - UNITS_PER_WORD;
> break;
>}
>
> regno++;
> }
> if (regno >= limit)
> return INVALID_REGNUM;
> else
> return regno;
> }
> ...
>
> for (regno = riscv_next_saved_reg (start, limit, &offset, false);
>regno != INVALID_REGNUM;
>regno = riscv_next_saved_reg (regno, limit, &offset))
> {
> ...
>
>
Ok, I see.
I changed it as follows (it will be retested before committing):
@@ -5531,7 +5531,8 @@ riscv_save_restore_reg (machine_mode mode, int regno,
/* Return the next register up from REGNO up to LIMIT for the callee
to save or restore. OFFSET will be adjusted accordingly.
- If INC is set, then REGNO will be incremented first. */
+ If INC is set, then REGNO will be incremented first.
+ Returns INVALID_REGNUM if there is no such next register. */
static unsigned int
riscv_next_saved_reg (unsigned int regno, unsigned int limit,
@@ -5545,12 +5546,12 @@ riscv_next_saved_reg (unsigned int regno, unsigned
int limit,
if (BITSET_P (cfun->machine->frame.mask, regno - GP_REG_FIRST))
{
*offset = *offset - UNITS_PER_WORD;
- break;
+ return regno;
}
regno++;
}
- return regno;
+ return INVALID_REGNUM;
}
/* Return TRUE if provided REGNO is eh return data register. */
@@ -5589,7 +5590,7 @@ riscv_for_each_saved_reg (poly_int64 sp_offset,
riscv_save_restore_fn fn,
offset = (cfun->machine->frame.gp_sp_offset - sp_offset).to_constant ()
+ UNITS_PER_WORD;
for (regno = riscv_next_saved_reg (start, limit, &offset, false);
- regno <= limit;
+ regno != INVALID_REGNUM;
Thanks!
> On Mon, Dec 19, 2022 at 5:21 PM Christoph Müllner
> wrote:
> >
> >
> >
> > On Mon, Dec 19, 2022 at 7:30 AM Kito Cheng
> wrote:
> >>
> >> just one more nit: Use INVALID_REGNUM as sentinel value for
> >> riscv_next_saved_reg, otherwise LGTM, and feel free to commit that
> >> separately :)
> >
> >
> > Would this change below be ok?
> >
> > @@ -5540,7 +5540,7 @@ riscv_next_saved_reg (unsigned int regno, unsigned
> int limit,
> >if (inc)
> > regno++;
> >
> > - while (regno <= limit)
> > + while (regno <= limit && regno != INVALID_REGNUM)
> > {
> >if (BITSET_P (cfun->machine->frame.mask, regno - GP_REG_FIRST))
> > {
> >
> > Thanks,
> > Christoph
> >
> >
> >>
> >>
> >> On Mon, Dec 19, 2022 at 9:08 AM Christoph Muellner
> >> wrote:
> >> >
> >> > From: Christoph Müllner
> >> >
> >> > This patch restructures the loop over the GP registers
> >> > which saves/restores then as part of the prologue/epilogue.
> >> > No functional change is intended by this patch, but it
> >> > offers the possibility to use load-pair/store-pair instructions.
> >> >
> >> > gcc/ChangeLog:
> >> >
> >> > * config/riscv/riscv.cc (riscv_next_saved_reg): New function.
> >> > (riscv_is_eh_return_data_register): New function.
> >> > (riscv_for_each_saved_reg): Restructure loop.
> >> >
> >> > Signed-off-by: Christoph Müllner
> >> > ---
> >> > gcc/config/riscv/riscv.cc | 94
> +++
> >> > 1 file changed, 66 insertions(+), 28 deletions(-)
> >> >
> >> > diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> >> > index 6dd2ab2d11e..a8d5e1dac7f 100644
> >> > --- a/gcc/config/riscv/riscv.cc
> >> > +++ b/gcc/config/riscv/riscv.cc
> >> > @@ -4835,6 +4835,49 @@ riscv_save_restore_reg (machine_mode mode, int
> regno,
> >> >fn (gen_rtx_REG (mode, regno), mem);
> >> > }
> >> >
> >> > +/* Return the next register up from REGNO up to LIMIT for the callee
> >> > + to save or restore. OFFSET will be adjusted accordingly.
> >> > + If INC is set, then REGNO will be incremented first. */
> >> > +
> >> > +static unsigned int
> >> > +riscv_next_saved_r
Re: [PATCH v2 02/11] riscv: Restructure callee-saved register save/restore code
On Mon, Dec 19, 2022 at 7:30 AM Kito Cheng wrote:
> just one more nit: Use INVALID_REGNUM as sentinel value for
> riscv_next_saved_reg, otherwise LGTM, and feel free to commit that
> separately :)
>
Would this change below be ok?
@@ -5540,7 +5540,7 @@ riscv_next_saved_reg (unsigned int regno, unsigned
int limit,
if (inc)
regno++;
- while (regno <= limit)
+ while (regno <= limit && regno != INVALID_REGNUM)
{
if (BITSET_P (cfun->machine->frame.mask, regno - GP_REG_FIRST))
{
Thanks,
Christoph
>
> On Mon, Dec 19, 2022 at 9:08 AM Christoph Muellner
> wrote:
> >
> > From: Christoph Müllner
> >
> > This patch restructures the loop over the GP registers
> > which saves/restores then as part of the prologue/epilogue.
> > No functional change is intended by this patch, but it
> > offers the possibility to use load-pair/store-pair instructions.
> >
> > gcc/ChangeLog:
> >
> > * config/riscv/riscv.cc (riscv_next_saved_reg): New function.
> > (riscv_is_eh_return_data_register): New function.
> > (riscv_for_each_saved_reg): Restructure loop.
> >
> > Signed-off-by: Christoph Müllner
> > ---
> > gcc/config/riscv/riscv.cc | 94 +++
> > 1 file changed, 66 insertions(+), 28 deletions(-)
> >
> > diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> > index 6dd2ab2d11e..a8d5e1dac7f 100644
> > --- a/gcc/config/riscv/riscv.cc
> > +++ b/gcc/config/riscv/riscv.cc
> > @@ -4835,6 +4835,49 @@ riscv_save_restore_reg (machine_mode mode, int
> regno,
> >fn (gen_rtx_REG (mode, regno), mem);
> > }
> >
> > +/* Return the next register up from REGNO up to LIMIT for the callee
> > + to save or restore. OFFSET will be adjusted accordingly.
> > + If INC is set, then REGNO will be incremented first. */
> > +
> > +static unsigned int
> > +riscv_next_saved_reg (unsigned int regno, unsigned int limit,
> > + HOST_WIDE_INT *offset, bool inc = true)
> > +{
> > + if (inc)
> > +regno++;
> > +
> > + while (regno <= limit)
> > +{
> > + if (BITSET_P (cfun->machine->frame.mask, regno - GP_REG_FIRST))
> > + {
> > + *offset = *offset - UNITS_PER_WORD;
> > + break;
> > + }
> > +
> > + regno++;
> > +}
> > + return regno;
> > +}
> > +
> > +/* Return TRUE if provided REGNO is eh return data register. */
> > +
> > +static bool
> > +riscv_is_eh_return_data_register (unsigned int regno)
> > +{
> > + unsigned int i, regnum;
> > +
> > + if (!crtl->calls_eh_return)
> > +return false;
> > +
> > + for (i = 0; (regnum = EH_RETURN_DATA_REGNO (i)) != INVALID_REGNUM;
> i++)
> > +if (regno == regnum)
> > + {
> > + return true;
> > + }
> > +
> > + return false;
> > +}
> > +
> > /* Call FN for each register that is saved by the current function.
> > SP_OFFSET is the offset of the current stack pointer from the start
> > of the frame. */
> > @@ -4844,36 +4887,31 @@ riscv_for_each_saved_reg (poly_int64 sp_offset,
> riscv_save_restore_fn fn,
> > bool epilogue, bool maybe_eh_return)
> > {
> >HOST_WIDE_INT offset;
> > + unsigned int regno;
> > + unsigned int start = GP_REG_FIRST;
> > + unsigned int limit = GP_REG_LAST;
> >
> >/* Save the link register and s-registers. */
> > - offset = (cfun->machine->frame.gp_sp_offset - sp_offset).to_constant
> ();
> > - for (unsigned int regno = GP_REG_FIRST; regno <= GP_REG_LAST; regno++)
> > -if (BITSET_P (cfun->machine->frame.mask, regno - GP_REG_FIRST))
> > - {
> > - bool handle_reg =
> !cfun->machine->reg_is_wrapped_separately[regno];
> > -
> > - /* If this is a normal return in a function that calls the
> eh_return
> > - builtin, then do not restore the eh return data registers as
> that
> > - would clobber the return value. But we do still need to save
> them
> > - in the prologue, and restore them for an exception return, so
> we
> > - need special handling here. */
> > - if (epilogue && !maybe_eh_return && crtl->calls_eh_return)
> > - {
> > - unsigned int i, regnum;
> > -
> > - for (i = 0; (regnum = EH_RETURN_DATA_REGNO (i)) !=
> INVALID_REGNUM;
> > -
Re: [PATCH] RISC-V: Add ABI requirement for XTheadFMemIdx tests
On Tue, Nov 7, 2023 at 2:19 AM Kito Cheng wrote:
>
> LGTM, and maybe change stdint.h to stdint-gcc.h in
> xtheadmemidx-helpers.h? that could make it more portable on multi-lib
> testing.
Can be found here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635508.html
Thanks!
>
> On Tue, Nov 7, 2023 at 3:44 AM Christoph Muellner
> wrote:
> >
> > From: Christoph Müllner
> >
> > The XTheadFMemIdx tests set the required ABI for RV32, but not
> > for RV64, which has the effect that the tests are expected to
> > succeed for RV64/LP64. Let's set the ABI to LP64D in these
> > tests to clarify the requirements.
> >
> > Signed-off-by: Christoph Müllner
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/riscv/xtheadfmemidx-index-update.c: Add ABI.
> > * gcc.target/riscv/xtheadfmemidx-index-xtheadbb-update.c: Likewise.
> > * gcc.target/riscv/xtheadfmemidx-index-xtheadbb.c: Likewise.
> > * gcc.target/riscv/xtheadfmemidx-index.c: Likewise.
> > * gcc.target/riscv/xtheadfmemidx-uindex-update.c: Likewise.
> > * gcc.target/riscv/xtheadfmemidx-uindex-xtheadbb-update.c: Likewise.
> > * gcc.target/riscv/xtheadfmemidx-uindex-xtheadbb.c: Likewise.
> > * gcc.target/riscv/xtheadfmemidx-uindex.c: Likewise.
> > ---
> > gcc/testsuite/gcc.target/riscv/xtheadfmemidx-index-update.c | 2 +-
> > .../gcc.target/riscv/xtheadfmemidx-index-xtheadbb-update.c | 2 +-
> > gcc/testsuite/gcc.target/riscv/xtheadfmemidx-index-xtheadbb.c | 2 +-
> > gcc/testsuite/gcc.target/riscv/xtheadfmemidx-index.c| 2 +-
> > gcc/testsuite/gcc.target/riscv/xtheadfmemidx-uindex-update.c| 2 +-
> > .../gcc.target/riscv/xtheadfmemidx-uindex-xtheadbb-update.c | 2 +-
> > gcc/testsuite/gcc.target/riscv/xtheadfmemidx-uindex-xtheadbb.c | 2 +-
> > gcc/testsuite/gcc.target/riscv/xtheadfmemidx-uindex.c | 2 +-
> > 8 files changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/gcc/testsuite/gcc.target/riscv/xtheadfmemidx-index-update.c
> > b/gcc/testsuite/gcc.target/riscv/xtheadfmemidx-index-update.c
> > index 24bbb63d174..cb86b8ad296 100644
> > --- a/gcc/testsuite/gcc.target/riscv/xtheadfmemidx-index-update.c
> > +++ b/gcc/testsuite/gcc.target/riscv/xtheadfmemidx-index-update.c
> > @@ -1,6 +1,6 @@
> > /* { dg-do compile } */
> > /* { dg-skip-if "" { *-*-* } { "-O0" "-O1" "-Og" } } */
> > -/* { dg-options "-march=rv64gc_xtheadmemidx_xtheadfmemidx" { target { rv64
> > } } } */
> > +/* { dg-options "-march=rv64gc_xtheadmemidx_xtheadfmemidx -mabi=lp64d" {
> > target { rv64 } } } */
> > /* { dg-options "-march=rv32imafc_xtheadmemidx_xtheadfmemidx -mabi=ilp32f"
> > { target { rv32 } } } */
> >
> > #include "xtheadmemidx-helpers.h"
> > diff --git
> > a/gcc/testsuite/gcc.target/riscv/xtheadfmemidx-index-xtheadbb-update.c
> > b/gcc/testsuite/gcc.target/riscv/xtheadfmemidx-index-xtheadbb-update.c
> > index 3b931a4b980..cc3f6219c05 100644
> > --- a/gcc/testsuite/gcc.target/riscv/xtheadfmemidx-index-xtheadbb-update.c
> > +++ b/gcc/testsuite/gcc.target/riscv/xtheadfmemidx-index-xtheadbb-update.c
> > @@ -1,6 +1,6 @@
> > /* { dg-do compile } */
> > /* { dg-skip-if "" { *-*-* } { "-O0" "-O1" "-Og" } } */
> > -/* { dg-options "-march=rv64gc_xtheadbb_xtheadmemidx_xtheadfmemidx" {
> > target { rv64 } } } */
> > +/* { dg-options "-march=rv64gc_xtheadbb_xtheadmemidx_xtheadfmemidx
> > -mabi=lp64d" { target { rv64 } } } */
> > /* { dg-options "-march=rv32imafc_xtheadbb_xtheadmemidx_xtheadfmemidx
> > -mabi=ilp32f" { target { rv32 } } } */
> >
> > #include "xtheadmemidx-helpers.h"
> > diff --git a/gcc/testsuite/gcc.target/riscv/xtheadfmemidx-index-xtheadbb.c
> > b/gcc/testsuite/gcc.target/riscv/xtheadfmemidx-index-xtheadbb.c
> > index 48858605c24..8ee98c87469 100644
> > --- a/gcc/testsuite/gcc.target/riscv/xtheadfmemidx-index-xtheadbb.c
> > +++ b/gcc/testsuite/gcc.target/riscv/xtheadfmemidx-index-xtheadbb.c
> > @@ -1,6 +1,6 @@
> > /* { dg-do compile } */
> > /* { dg-skip-if "" { *-*-* } { "-O0" "-O1" "-Og" } } */
> > -/* { dg-options "-march=rv64gc_xtheadbb_xtheadmemidx_xtheadfmemidx" {
> > target { rv64 } } } */
> > +/* { dg-options "-march=rv64gc_xtheadbb_xtheadmemidx_xtheadfmemidx
> > -mabi=lp64d" { target { rv64 } } } */
> > /* { dg-options &qu
Re: [PATCH] RISC-V: Use stdint-gcc.h in rvv testsuite
On Tue, Nov 7, 2023 at 11:16 AM Kito Cheng wrote: > > LGTM, but title is little bit misleading, it's not really related to rvv, > change to either RISC-V or T-head is fine, anyway, you can commit without > send v2 :) Fixed and pushed. Thanks! > > Christoph Muellner 於 2023年11月7日 週二 17:45 寫道： >> >> From: Christoph Müllner >> >> stdint.h can be replaced with stdint-gcc.h to resolve some missing >> system headers in non-multilib installations. >> >> gcc/testsuite/ChangeLog: >> >> * gcc.target/riscv/xtheadmemidx-helpers.h: >> Replace stdint.h with stdint-gcc.h. >> >> Signed-off-by: Christoph Müllner >> --- >> gcc/testsuite/gcc.target/riscv/xtheadmemidx-helpers.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/gcc/testsuite/gcc.target/riscv/xtheadmemidx-helpers.h >> b/gcc/testsuite/gcc.target/riscv/xtheadmemidx-helpers.h >> index a97f08c5cc1..9d8ce124a93 100644 >> --- a/gcc/testsuite/gcc.target/riscv/xtheadmemidx-helpers.h >> +++ b/gcc/testsuite/gcc.target/riscv/xtheadmemidx-helpers.h >> @@ -1,7 +1,7 @@ >> #ifndef XTHEADMEMIDX_HELPERS_H >> #define XTHEADMEMIDX_HELPERS_H >> >> -#include >> +#include >> >> #define intX_t long >> #define uintX_t unsigned long >> -- >> 2.41.0 >>
Re: [PATCH] minimal support for xtheadv
On Thu, Nov 9, 2023 at 8:39 AM Kito Cheng wrote:
>
> Hi Yi Xuan:
>
> This patch is trivial, and generally LGTM, but I would require putting
> the spec into https://github.com/riscv-non-isa/riscv-toolchain-conventions
> before merging this, also don't forget include "RISC-V:" in the title,
> it would be easier to track during the RISC-V GCC sync meeting :)
>
> And I am a little bit confused by the author's info? is it from you or
> "XYenChi "? or oriachi...@gmail.com is also your
> mail address?
>
> cc Christoph since I believe you may know more about that process.
> cc JoJo since you are T-head folk :P
Hi Yi Xuan and Kito,
I was not aware that CAS is working on getting T-Head's Vector
extension supported.
My biggest concern with this patch is that "XTheadV" does not have a
specification.
T-Head and VRULL are currently working on support patches for T-Head's
Vector extension
implementation. We've named the extension XTheadVector.
Supporting XTheadVector means to address a range of issues (e.g.
defining a formal ISA
vendor extension specification, extension discovery, addressing
implementation details,
differences among available cores, intrinsics, ...).
We've already made good progress on that and expect to publish first
results soon.
BR
Christoph
>
>
> On Wed, Nov 8, 2023 at 9:13 PM wrote:
> >
> > From: XYenChi
> >
> > This patch is for support xtheadv.
> >
> > gcc/ChangeLog:
> >
> > 2023-11-08 Chen Yixuan
> >
> > * common/config/riscv/riscv-common.cc: Add xthead minimal support.
> >
> > gcc/config/ChangeLog:
> >
> > 2023-11-08 Chen Yixuan
> >
> > * riscv/riscv.opt: Add xthead minimal support.
> > ---
> > gcc/common/config/riscv/riscv-common.cc | 2 ++
> > gcc/config/riscv/riscv.opt | 2 ++
> > 2 files changed, 4 insertions(+)
> >
> > diff --git a/gcc/common/config/riscv/riscv-common.cc
> > b/gcc/common/config/riscv/riscv-common.cc
> > index 526dbb7603b..d5ea0ee9b70 100644
> > --- a/gcc/common/config/riscv/riscv-common.cc
> > +++ b/gcc/common/config/riscv/riscv-common.cc
> > @@ -325,6 +325,7 @@ static const struct riscv_ext_version
> > riscv_ext_version_table[] =
> >{"xtheadmemidx", ISA_SPEC_CLASS_NONE, 1, 0},
> >{"xtheadmempair", ISA_SPEC_CLASS_NONE, 1, 0},
> >{"xtheadsync", ISA_SPEC_CLASS_NONE, 1, 0},
> > + {"xtheadv",ISA_SPEC_CLASS_NONE, 0, 7},
> >
> >{"xventanacondops", ISA_SPEC_CLASS_NONE, 1, 0},
> >
> > @@ -1680,6 +1681,7 @@ static const riscv_ext_flag_table_t
> > riscv_ext_flag_table[] =
> >{"xtheadmemidx", &gcc_options::x_riscv_xthead_subext,
> > MASK_XTHEADMEMIDX},
> >{"xtheadmempair", &gcc_options::x_riscv_xthead_subext,
> > MASK_XTHEADMEMPAIR},
> >{"xtheadsync",&gcc_options::x_riscv_xthead_subext, MASK_XTHEADSYNC},
> > + {"xtheadv", &gcc_options::x_riscv_xthead_subext, MASK_XTHEADV},
> >
> >{"xventanacondops", &gcc_options::x_riscv_xventana_subext,
> > MASK_XVENTANACONDOPS},
> >
> > diff --git a/gcc/config/riscv/riscv.opt b/gcc/config/riscv/riscv.opt
> > index 70d78151cee..2bbdf680fa2 100644
> > --- a/gcc/config/riscv/riscv.opt
> > +++ b/gcc/config/riscv/riscv.opt
> > @@ -438,6 +438,8 @@ Mask(XTHEADMEMPAIR) Var(riscv_xthead_subext)
> >
> > Mask(XTHEADSYNC)Var(riscv_xthead_subext)
> >
> > +Mask(XTHEADV) Var(riscv_xthead_subext)
> > +
> > TargetVariable
> > int riscv_xventana_subext
> >
> > --
> > 2.42.0
> >
Re: [PATCH] RISC-V: Fix the illegal operands for the XTheadMemidx extension.
On Thu, Nov 9, 2023 at 8:40 AM Jin Ma wrote:
>
> The pattern "*extend2_bitmanip" and
> "*zero_extendhi2_bitmanip" in bitmanip.md are similar
> to the pattern "*th_memidx_bb_extendqi2" and
> "*th_memidx_bb_zero_extendhi2" in thead.md, which will
> cause the wrong instruction to be generated and report the
> following error in binutils:
> Assembler messages:
> Error: illegal operands `lb a5,(a0),1,0'
>
> In fact, the correct instruction is "th.lbia a5,(a0),1,0".
LGTM.
This zbb_xtheadmemidx was not part of the test matrix.
We only had xtheadbb_xtheadmemidx there.
Thanks!
>
> gcc/ChangeLog:
>
> * config/riscv/bitmanip.md: Avoid the conflict between
> zbb and xtheadmemidx in patterns.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/xtheadfmemidx-uindex-zbb.c: New test.
> ---
> gcc/config/riscv/bitmanip.md | 4 +--
> .../riscv/xtheadfmemidx-uindex-zbb.c | 30 +++
> 2 files changed, 32 insertions(+), 2 deletions(-)
> create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadfmemidx-uindex-zbb.c
>
> diff --git a/gcc/config/riscv/bitmanip.md b/gcc/config/riscv/bitmanip.md
> index a9c8275fca7..878395c3ffa 100644
> --- a/gcc/config/riscv/bitmanip.md
> +++ b/gcc/config/riscv/bitmanip.md
> @@ -290,7 +290,7 @@ (define_insn "*di2"
> (define_insn "*zero_extendhi2_bitmanip"
>[(set (match_operand:GPR 0 "register_operand" "=r,r")
> (zero_extend:GPR (match_operand:HI 1 "nonimmediate_operand" "r,m")))]
> - "TARGET_ZBB"
> + "TARGET_ZBB && !TARGET_XTHEADMEMIDX"
>"@
> zext.h\t%0,%1
> lhu\t%0,%1"
> @@ -301,7 +301,7 @@ (define_insn "*extend2_bitmanip"
>[(set (match_operand:SUPERQI 0 "register_operand" "=r,r")
> (sign_extend:SUPERQI
> (match_operand:SHORT 1 "nonimmediate_operand" " r,m")))]
> - "TARGET_ZBB"
> + "TARGET_ZBB && !TARGET_XTHEADMEMIDX"
>"@
> sext.\t%0,%1
> l\t%0,%1"
> diff --git a/gcc/testsuite/gcc.target/riscv/xtheadfmemidx-uindex-zbb.c
> b/gcc/testsuite/gcc.target/riscv/xtheadfmemidx-uindex-zbb.c
> new file mode 100644
> index 000..a05bc220cba
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/xtheadfmemidx-uindex-zbb.c
> @@ -0,0 +1,30 @@
> +/* { dg-do compile } */
> +/* { dg-skip-if "" { *-*-* } { "-O0" "-O1" "-Og" } } */
> +/* { dg-options "-march=rv64gc_zbb_xtheadmemidx -mabi=lp64d" { target { rv64
> } } } */
> +/* { dg-options "-march=rv32imafc_zbb_xtheadmemidx -mabi=ilp32f" { target {
> rv32 } } } */
> +
> +const unsigned char *
> +read_uleb128(const unsigned char *p, unsigned long *val)
> +{
> + unsigned int shift = 0;
> + unsigned char byte;
> + unsigned long result;
> +
> + result = 0;
> + do
> + {
> +byte = *p++;
> +result |= ((unsigned long)byte & 0x7f) << shift;
> +shift += 7;
> + } while (byte & 0x80);
> +
> + *val = result;
> + return p;
> +}
> +
> +void test(const unsigned char *p, unsigned long utmp)
> +{
> + p = read_uleb128(p, &utmp);
> +}
> +
> +/* { dg-final { scan-assembler-not {\mlb\ta[0-9],\(a[0-9]\),1,0\M} } } */
>
> base-commit: 04d8a47608dcae7f61805e3566e3a1571b574405
> --
> 2.17.1
>
Re: [PATCH] RISC-V: Fix bug that XTheadMemPair extension caused fcsr not to be saved and restored before and after interrupt.
On Fri, Nov 10, 2023 at 8:14 AM Jin Ma wrote:
>
> The t0 register is used as a temporary register for interrupts, so it needs
> special treatment. It is necessary to avoid using "th.ldd" in the interrupt
> program to stop the subsequent operation of the t0 register, so they need to
> exchange positions in the function "riscv_for_each_saved_reg".
RISCV_PROLOGUE_TEMP_REGNUM needs indeed to be treated special
in case of ISRs and fcsr. This patch just moves the TARGET_XTHEADMEMPAIR
block after the ISR/fcsr block.
Reviewed-by: Christoph Müllner
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (riscv_for_each_saved_reg): Place the
> interrupt
> operation before the XTheadMemPair.
> ---
> gcc/config/riscv/riscv.cc | 56 +--
> .../riscv/xtheadmempair-interrupt-fcsr.c | 18 ++
> 2 files changed, 46 insertions(+), 28 deletions(-)
> create mode 100644
> gcc/testsuite/gcc.target/riscv/xtheadmempair-interrupt-fcsr.c
>
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index e25692b86fc..fa2d4d4b779 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -6346,6 +6346,34 @@ riscv_for_each_saved_reg (poly_int64 sp_offset,
> riscv_save_restore_fn fn,
> && riscv_is_eh_return_data_register (regno))
> continue;
>
> + /* In an interrupt function, save and restore some necessary CSRs in
> the stack
> +to avoid changes in CSRs. */
> + if (regno == RISCV_PROLOGUE_TEMP_REGNUM
> + && cfun->machine->interrupt_handler_p
> + && ((TARGET_HARD_FLOAT && cfun->machine->frame.fmask)
> + || (TARGET_ZFINX
> + && (cfun->machine->frame.mask & ~(1 <<
> RISCV_PROLOGUE_TEMP_REGNUM)
> + {
> + unsigned int fcsr_size = GET_MODE_SIZE (SImode);
> + if (!epilogue)
> + {
> + riscv_save_restore_reg (word_mode, regno, offset, fn);
> + offset -= fcsr_size;
> + emit_insn (gen_riscv_frcsr (RISCV_PROLOGUE_TEMP (SImode)));
> + riscv_save_restore_reg (SImode, RISCV_PROLOGUE_TEMP_REGNUM,
> + offset, riscv_save_reg);
> + }
> + else
> + {
> + riscv_save_restore_reg (SImode, RISCV_PROLOGUE_TEMP_REGNUM,
> + offset - fcsr_size, riscv_restore_reg);
> + emit_insn (gen_riscv_fscsr (RISCV_PROLOGUE_TEMP (SImode)));
> + riscv_save_restore_reg (word_mode, regno, offset, fn);
> + offset -= fcsr_size;
> + }
> + continue;
> + }
> +
>if (TARGET_XTHEADMEMPAIR)
> {
> /* Get the next reg/offset pair. */
> @@ -6376,34 +6404,6 @@ riscv_for_each_saved_reg (poly_int64 sp_offset,
> riscv_save_restore_fn fn,
> }
> }
>
> - /* In an interrupt function, save and restore some necessary CSRs in
> the stack
> -to avoid changes in CSRs. */
> - if (regno == RISCV_PROLOGUE_TEMP_REGNUM
> - && cfun->machine->interrupt_handler_p
> - && ((TARGET_HARD_FLOAT && cfun->machine->frame.fmask)
> - || (TARGET_ZFINX
> - && (cfun->machine->frame.mask & ~(1 <<
> RISCV_PROLOGUE_TEMP_REGNUM)
> - {
> - unsigned int fcsr_size = GET_MODE_SIZE (SImode);
> - if (!epilogue)
> - {
> - riscv_save_restore_reg (word_mode, regno, offset, fn);
> - offset -= fcsr_size;
> - emit_insn (gen_riscv_frcsr (RISCV_PROLOGUE_TEMP (SImode)));
> - riscv_save_restore_reg (SImode, RISCV_PROLOGUE_TEMP_REGNUM,
> - offset, riscv_save_reg);
> - }
> - else
> - {
> - riscv_save_restore_reg (SImode, RISCV_PROLOGUE_TEMP_REGNUM,
> - offset - fcsr_size, riscv_restore_reg);
> - emit_insn (gen_riscv_fscsr (RISCV_PROLOGUE_TEMP (SImode)));
> - riscv_save_restore_reg (word_mode, regno, offset, fn);
> - offset -= fcsr_size;
> - }
> - continue;
> - }
> -
>riscv_save_restore_reg (word_mode, regno, offset, fn);
> }
>
> diff --git a/gcc/testsuite/gcc.target/riscv/xtheadmempair-interrupt-fcsr.c
> b/gcc/testsuite/gcc.target/riscv/xtheadmempair-interrupt-fcsr.c
> new file mode 100644
> index 000..d06f05f5c7c
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/xtheadme
Re: [PATCH] RISC-V: Fix bug that XTheadMemPair extension caused fcsr not to be saved and restored before and after interrupt.
On Fri, Nov 10, 2023 at 2:20 PM Kito Cheng wrote:
>
> LGTM
Committed after shortening the commit message's heading.
>
> Christoph Müllner 於 2023年11月10日 週五，20:55寫道：
>>
>> On Fri, Nov 10, 2023 at 8:14 AM Jin Ma wrote:
>> >
>> > The t0 register is used as a temporary register for interrupts, so it needs
>> > special treatment. It is necessary to avoid using "th.ldd" in the interrupt
>> > program to stop the subsequent operation of the t0 register, so they need
>> > to
>> > exchange positions in the function "riscv_for_each_saved_reg".
>>
>> RISCV_PROLOGUE_TEMP_REGNUM needs indeed to be treated special
>> in case of ISRs and fcsr. This patch just moves the TARGET_XTHEADMEMPAIR
>> block after the ISR/fcsr block.
>>
>> Reviewed-by: Christoph Müllner
>>
>> >
>> > gcc/ChangeLog:
>> >
>> > * config/riscv/riscv.cc (riscv_for_each_saved_reg): Place the
>> > interrupt
>> > operation before the XTheadMemPair.
>> > ---
>> > gcc/config/riscv/riscv.cc | 56 +--
>> > .../riscv/xtheadmempair-interrupt-fcsr.c | 18 ++
>> > 2 files changed, 46 insertions(+), 28 deletions(-)
>> > create mode 100644
>> > gcc/testsuite/gcc.target/riscv/xtheadmempair-interrupt-fcsr.c
>> >
>> > diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
>> > index e25692b86fc..fa2d4d4b779 100644
>> > --- a/gcc/config/riscv/riscv.cc
>> > +++ b/gcc/config/riscv/riscv.cc
>> > @@ -6346,6 +6346,34 @@ riscv_for_each_saved_reg (poly_int64 sp_offset,
>> > riscv_save_restore_fn fn,
>> > && riscv_is_eh_return_data_register (regno))
>> > continue;
>> >
>> > + /* In an interrupt function, save and restore some necessary CSRs
>> > in the stack
>> > +to avoid changes in CSRs. */
>> > + if (regno == RISCV_PROLOGUE_TEMP_REGNUM
>> > + && cfun->machine->interrupt_handler_p
>> > + && ((TARGET_HARD_FLOAT && cfun->machine->frame.fmask)
>> > + || (TARGET_ZFINX
>> > + && (cfun->machine->frame.mask & ~(1 <<
>> > RISCV_PROLOGUE_TEMP_REGNUM)
>> > + {
>> > + unsigned int fcsr_size = GET_MODE_SIZE (SImode);
>> > + if (!epilogue)
>> > + {
>> > + riscv_save_restore_reg (word_mode, regno, offset, fn);
>> > + offset -= fcsr_size;
>> > + emit_insn (gen_riscv_frcsr (RISCV_PROLOGUE_TEMP (SImode)));
>> > + riscv_save_restore_reg (SImode, RISCV_PROLOGUE_TEMP_REGNUM,
>> > + offset, riscv_save_reg);
>> > + }
>> > + else
>> > + {
>> > + riscv_save_restore_reg (SImode, RISCV_PROLOGUE_TEMP_REGNUM,
>> > + offset - fcsr_size,
>> > riscv_restore_reg);
>> > + emit_insn (gen_riscv_fscsr (RISCV_PROLOGUE_TEMP (SImode)));
>> > + riscv_save_restore_reg (word_mode, regno, offset, fn);
>> > + offset -= fcsr_size;
>> > + }
>> > + continue;
>> > + }
>> > +
>> >if (TARGET_XTHEADMEMPAIR)
>> > {
>> > /* Get the next reg/offset pair. */
>> > @@ -6376,34 +6404,6 @@ riscv_for_each_saved_reg (poly_int64 sp_offset,
>> > riscv_save_restore_fn fn,
>> > }
>> > }
>> >
>> > - /* In an interrupt function, save and restore some necessary CSRs
>> > in the stack
>> > -to avoid changes in CSRs. */
>> > - if (regno == RISCV_PROLOGUE_TEMP_REGNUM
>> > - && cfun->machine->interrupt_handler_p
>> > - && ((TARGET_HARD_FLOAT && cfun->machine->frame.fmask)
>> > - || (TARGET_ZFINX
>> > - && (cfun->machine->frame.mask & ~(1 <<
>> > RISCV_PROLOGUE_TEMP_REGNUM)
>> > - {
>> > - unsigned int fcsr_size = GET_MODE_SIZE (SImode);
>> > - if (!epilogue)
>> > - {
>> > - riscv_save_restore_reg (word_mode, regno, offset, fn);
>> > - offset -= fcsr_size;
>> > - emit_insn (gen_riscv_frcsr (RISCV_P
Re: [PATCH] riscv: thead: Add support for the XTheadInt ISA extension
On Tue, Nov 7, 2023 at 4:04 AM Jin Ma wrote:
>
> The XTheadInt ISA extension provides acceleration interruption
> instructions as defined in T-Head-specific:
>
> * th.ipush
> * th.ipop
Overall, it looks ok to me.
There are just a few small issues to clean up (see below).
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-protos.h (th_int_get_mask): New prototype.
> (th_int_get_save_adjustment): Likewise.
> (th_int_adjust_cfi_prologue): Likewise.
> * config/riscv/riscv.cc (TH_INT_INTERRUPT): New macro.
> (riscv_expand_prologue): Add the processing of XTheadInt.
> (riscv_expand_epilogue): Likewise.
> * config/riscv/riscv.md: New unspec.
> * config/riscv/thead.cc (BITSET_P): New macro.
> * config/riscv/thead.md (th_int_push): New pattern.
> (th_int_pop): New pattern.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/xtheadint-push-pop.c: New test.
> ---
> gcc/config/riscv/riscv-protos.h | 3 +
> gcc/config/riscv/riscv.cc | 58 +-
> gcc/config/riscv/riscv.md | 4 +
> gcc/config/riscv/thead.cc | 78 +++
> gcc/config/riscv/thead.md | 67
> .../gcc.target/riscv/xtheadint-push-pop.c | 36 +
> 6 files changed, 245 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadint-push-pop.c
>
> diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
> index 85d4f6ed9ea..05d1fc2b3a0 100644
> --- a/gcc/config/riscv/riscv-protos.h
> +++ b/gcc/config/riscv/riscv-protos.h
> @@ -627,6 +627,9 @@ extern void th_mempair_prepare_save_restore_operands
> (rtx[4], bool,
> int, HOST_WIDE_INT,
> int, HOST_WIDE_INT);
> extern void th_mempair_save_restore_regs (rtx[4], bool, machine_mode);
> +extern unsigned int th_int_get_mask(unsigned int);
Space between function name and parenthesis.
> +extern unsigned int th_int_get_save_adjustment();
Space between function name and parenthesis.
An empty parameter list should be written as "(void)".
> +extern rtx th_int_adjust_cfi_prologue (unsigned int);
> #ifdef RTX_CODE
> extern const char*
> th_mempair_output_move (rtx[4], bool, machine_mode, RTX_CODE);
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index 08ff05dcc3f..c623101b05e 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -101,6 +101,16 @@ along with GCC; see the file COPYING3. If not see
> /* True the mode switching has static frm, or false. */
> #define STATIC_FRM_P(c) ((c)->machine->mode_sw_info.static_frm_p)
>
> +/* True if we can use the instructions in the XTheadInt extension
> + to handle interrupts, or false. */
> +#define TH_INT_INTERRUPT(c)\
> + (TARGET_XTHEADINT\
> + /* The XTheadInt extension only supports rv32. */ \
> + && !TARGET_64BIT\
> + && (c)->machine->interrupt_handler_p\
> + /* This instruction can be executed in M-mode only.*/ \
Dot, space, space, end of comment.
Maybe better:
/* The XTheadInt instructions can only be executed in M-mode. */
> + && (c)->machine->interrupt_mode == MACHINE_MODE)
> +
> /* Information about a function's frame layout. */
> struct GTY(()) riscv_frame_info {
>/* The size of the frame in bytes. */
> @@ -6703,6 +6713,7 @@ riscv_expand_prologue (void)
>unsigned fmask = frame->fmask;
>int spimm, multi_push_additional, stack_adj;
>rtx insn, dwarf = NULL_RTX;
> + unsigned th_int_mask = 0;
>
>if (flag_stack_usage_info)
> current_function_static_stack_size = constant_lower_bound
> (remaining_size);
> @@ -6771,6 +6782,28 @@ riscv_expand_prologue (void)
>REG_NOTES (insn) = dwarf;
> }
>
> + th_int_mask = th_int_get_mask(frame->mask);
There should be exactly one space between function name and parenthesis.
> + if (th_int_mask && TH_INT_INTERRUPT (cfun))
> +{
> + frame->mask &= ~th_int_mask;
> +
> + /* RISCV_PROLOGUE_TEMP may be used to handle some CSR for
> +interrupts, such as fcsr. */
Dot, space, space, end of comment.
> + if ((TARGET_HARD_FLOAT && frame->fmask)
> + || (TARGET_ZFINX && frame->mask))
> + frame->mask |= (1 << RISCV_PROLOGUE_TEMP_REGNUM);
> +
> + unsigned save_adjustment = th_int_get_save_adjustment ();
> + frame->gp_sp_offset -= save_adjustment;
> + remaining_size -= save_adjustment;
> +
> + insn = emit_insn (gen_th_int_push ());
> +
> + rtx dwarf = th_int_adjust_cfi_prologue (th_int_mask);
> + RTX_FRAME_RELATED_P (insn) = 1;
> + REG_NOTES (insn) = dwarf;
> +}
> +
>/* Save the GP, FP registers. */
>if
Re: [PATCH] RISC-V: Save/restore ra register correctly [PR112478]
On Tue, Nov 14, 2023 at 3:15 PM Kito Cheng wrote:
>
> We set ra to fixed register now, but we still need to save/restore that at
> prologue/epilogue if that has used.
So before 71f906498ada9 $ra was neither a fixed nor a used register.
Therefore, riscv_save_reg_p returned true in the first test (not global reg,
not used_or_fixed, and ever_live_p).
After this commit, this does not happen anymore, because the test for
not used_or_fixed fails and we don't test for ever_live_p in the following.
And this patch restores this behavior.
Reviewed-by: Christoph Müllner
Tested-by: Christoph Müllner
>
> gcc/ChangeLog:
>
> PR target/112478
> * config/riscv/riscv.cc (riscv_save_return_addr_reg_p): Check ra
> is ever lived.
>
> gcc/testsuite/gcc/ChangeLog:
>
> PR target/112478
> * riscv/pr112478.c: New.
> ---
> gcc/config/riscv/riscv.cc | 4
> gcc/testsuite/gcc.target/riscv/pr112478.c | 8
> 2 files changed, 12 insertions(+)
> create mode 100644 gcc/testsuite/gcc.target/riscv/pr112478.c
>
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index ecee7eb4727..f09c4066903 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -5802,6 +5802,10 @@ riscv_save_return_addr_reg_p (void)
>if (riscv_far_jump_used_p ())
> return true;
>
> + /* We need to save it if anyone has used that. */
> + if (df_regs_ever_live_p (RETURN_ADDR_REGNUM))
> +return true;
> +
>/* Need not to use ra for leaf when frame pointer is turned off by
> option whatever the omit-leaf-frame's value. */
>if (frame_pointer_needed && crtl->is_leaf
> diff --git a/gcc/testsuite/gcc.target/riscv/pr112478.c
> b/gcc/testsuite/gcc.target/riscv/pr112478.c
> new file mode 100644
> index 000..0bbde20b71b
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/pr112478.c
> @@ -0,0 +1,8 @@
> +/* { dg-do compile } */
> +/* { dg-options "-ffat-lto-objects" } */
> +
> +void foo() {
> +asm volatile("# " : ::"ra");
> +}
> +
> +/* { dg-final { scan-assembler "s(w|d)\[ \t\]*ra" } } */
> --
> 2.40.1
>
Re: [PATCH v2] RISC-V: Implement target attribute
On Tue, Nov 14, 2023 at 3:15 PM Kito Cheng wrote:
>
> The target attribute which proposed in [1], target attribute allow user
> to specify a local setting per-function basis.
>
> The syntax of target attribute is `__attribute__((target("")))`.
>
> and the syntax of `` describes below:
> ```
> ATTR-STRING := ATTR-STRING ';' ATTR
> | ATTR
>
> ATTR:= ARCH-ATTR
> | CPU-ATTR
> | TUNE-ATTR
>
> ARCH-ATTR := 'arch=' EXTENSIONS-OR-FULLARCH
>
> EXTENSIONS-OR-FULLARCH :=
> |
>
> EXTENSIONS := ','
> |
>
> FULLARCHSTR:=
>
> EXTENSION :=
>
> OP := '+'
>
> VERSION:= [0-9]+ 'p' [0-9]+
> | [1-9][0-9]*
> |
>
> EXTENSION-NAME := Naming rule is defined in RISC-V ISA manual
>
> CPU-ATTR:= 'cpu='
> TUNE-ATTR := 'tune='
> ```
>
> Changes since v1:
> - Use std::unique_ptr rather than alloca to prevent memory issue.
> - Error rather than warning when attribute duplicated.
>
> [1] https://github.com/riscv-non-isa/riscv-c-api-doc/pull/35
I've reviewed with a focus on the utilized backend hooks and macros.
Reviewed-by: Christoph Müllner
Note, that in the changelog below there are quite many empty entries.
>
> gcc/ChangeLog:
>
> * config.gcc (riscv): Add riscv-target-attr.o.
> * config/riscv/riscv-protos.h (riscv_declare_function_size) New.
> (riscv_option_valid_attribute_p): New.
> (riscv_override_options_internal): New.
> (struct riscv_tune_info): New.
> (riscv_parse_tune): New.
> * config/riscv/riscv-target-attr.cc
> (class riscv_target_attr_parser): New.
> (struct riscv_attribute_info): New.
> (riscv_attributes): New.
> (riscv_target_attr_parser::parse_arch):
> (riscv_target_attr_parser::handle_arch):
> (riscv_target_attr_parser::handle_cpu):
> (riscv_target_attr_parser::handle_tune):
> (riscv_target_attr_parser::update_settings):
> (riscv_process_one_target_attr):
> (num_occurences_in_str):
> (riscv_process_target_attr):
> (riscv_option_valid_attribute_p):
> * config/riscv/riscv.cc: Include target-globals.h and
> riscv-subset.h.
> (struct riscv_tune_info): Move to riscv-protos.h.
> (get_tune_str):
> (riscv_parse_tune):
> (riscv_declare_function_size):
> (riscv_option_override): Build target_option_default_node and
> target_option_current_node.
> (riscv_save_restore_target_globals):
> (riscv_option_restore):
> (riscv_previous_fndecl):
> (riscv_set_current_function): Apply the target attribute.
> (TARGET_OPTION_RESTORE): Define.
> (TARGET_OPTION_VALID_ATTRIBUTE_P): Ditto.
> * config/riscv/riscv.h (SWITCHABLE_TARGET): Define to 1.
> (ASM_DECLARE_FUNCTION_SIZE) Define.
> * config/riscv/riscv.opt (mtune=): Add Save attribute.
> (mcpu=): Ditto.
> (mcmodel=): Ditto.
> * config/riscv/t-riscv: Add build rule for riscv-target-attr.o
> * doc/extend.texi: Add doc for target attribute.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/target-attr-01.c: New.
> * gcc.target/riscv/target-attr-02.c: Ditto.
> * gcc.target/riscv/target-attr-03.c: Ditto.
> * gcc.target/riscv/target-attr-04.c: Ditto.
> * gcc.target/riscv/target-attr-05.c: Ditto.
> * gcc.target/riscv/target-attr-06.c: Ditto.
> * gcc.target/riscv/target-attr-07.c: Ditto.
> * gcc.target/riscv/target-attr-bad-01.c: Ditto.
> * gcc.target/riscv/target-attr-bad-02.c: Ditto.
> * gcc.target/riscv/target-attr-bad-03.c: Ditto.
> * gcc.target/riscv/target-attr-bad-04.c: Ditto.
> * gcc.target/riscv/target-attr-bad-05.c: Ditto.
> * gcc.target/riscv/target-attr-bad-06.c: Ditto.
> * gcc.target/riscv/target-attr-bad-07.c: Ditto.
> * gcc.target/riscv/target-attr-bad-08.c: Ditto.
> * gcc.target/riscv/target-attr-bad-09.c: Ditto.
> * gcc.target/riscv/target-attr-bad-10.c: Ditto.
> ---
> gcc/config.gcc| 2 +-
> gcc/config/riscv/riscv-protos.h | 21 +
> gcc/config/riscv/riscv-target-attr.cc | 395 ++
> gcc/config/riscv/riscv.cc | 192 +++--
> gcc/config/riscv/riscv.h | 6 +
Re: RISC-V: Support XTheadVector extensions
On Fri, Nov 17, 2023 at 12:40 PM juzhe.zh...@rivai.ai
wrote:
>
> 90% theadvector extension reusing current RVV 1.0 instructions patterns:
> Just change ASM, For example:
>
> @@ -2923,7 +2923,7 @@ (define_insn "*pred_mulh_scalar"
> (match_operand:VFULLI_D 3 "register_operand" "vr,vr, vr, vr")] VMULH)
>(match_operand:VFULLI_D 2 "vector_merge_operand" "vu, 0, vu, 0")))]
>"TARGET_VECTOR"
> - "vmulh.vx\t%0,%3,%z4%p1"
> + "%^vmulh.vx\t%0,%3,%z4%p1"
>[(set_attr "type" "vimul")
> (set_attr "mode" "")])
>
> + if (letter == '^')
> +{
> + if (TARGET_XTHEADVECTOR)
> + fputs ("th.", file);
> + return;
> +}
>
>
> For almost all patterns, you just simply append "th." in the ASM prefix.
> like change "vmulh.vv" -> "th.vmulh.vv"
>
> Almost all theadvector instructions are not new features, all same as RVV1.0.
> Why do you invent the such ISA doesn't include any features that RVV1.0
> doesn't satisfy ?
>
> I am not explicitly object this patch. But I should know the reason.
Palmer already outlined the reason why this has been implemented in HW.
I want to add some comments on the specification and the design of the
SW support.
We have to face the fact here, that T-Head implemented the 0.7.1 draft
version of RVV (plus a VLENB CSR).
I don't want to waste time and discuss who is to blame for that (this
has been done elsewhere in enough detail).
Also, there are mechanisms now in place to avoid that something like
this happens again.
When we call this extension "RVV-0.7.1-draft" (plus VLENB), then we
are facing arguments that
claim that a RVV "draft" cannot be treated as a ratified extension.
Further, there are arguments
that only one RVV extension exists (the one that was ratified).
Therefore, T-Head's vector extension was
several times described as a "custom-extension", which is
"non-conforming" (uses encoding space
of standard extension). Of course, this hides the fact that the
extension is identical to RVV 1.0 to a high degree.
Anyway, I don't think that these arguments and descriptions are wrong.
So, in order to avoid pointless discussions about what it is, and why
it is what it is,
we simply accepted this description and gave the extension the name
XTheadVector.
In RISC-V vendor instructions and CSRs need to have vendor prefixes ("th.").
The specification can be found (together with all other XThead*
extensions) here:
https://github.com/T-head-Semi/thead-extension-spec/blob/master/xtheadvector.adoc
Some further details, which are worth mentioning here about this specification:
* Factional LMUL values are not supported.
* Zvlsseg was an extension in RVV 0.7.1, but is part in RVV 1.0.
Since T-Head has these instructions as well, we followed the RVV 1.0
idea and made
these instructions mandatory for XTheadVector (ie. avoiding
introduction of useless extensions).
* Zvamo was an extension in RVV 0.7.1, which was dropped in RVV 1.0.
Since T-Head has these instructions as well, we defined XTheadZvamo.
So the result is that we have a custom extension, which uses the RVI
encoding space
and which "by accident" has a huge overlap with RVV 1.0.
We are all fine with this, as long as this is our ticket to get the
extension supported upstream
(in the sense that everyone's opinions are respected and a solution is
found which
will not trigger useless discussions about things that happened a long
time ago).
The implementation follows this idea: it is a vendor extension and is
kept as separate
as possible from standard extensions. However, avoid duplication was
one of our most important
goals, so we came up with reusing the overlapping functionality by
just adding the instruction prefixes.
For the intrinsics API, we use a more user-friendly (pragmatic) approach:
* state the set of supported RVV intrinsic functions
* state the missing support of fractional LMUL values
* list the extension-specific intrinsic functions for the additional
load/store functionality
I hope this gives a good overview of our reasoning.
Let me know if you have further questions.
BR
Christoph
>
> Btw, stage 1 will close soon. So I will review this patch on GCC-15 as long
> as all other RISC-V maintainers agree.
>
>
>
> juzhe.zh...@rivai.ai
Re: RISC-V: Support XTheadVector extensions
Hi Juzhe,
Sorry for the late reply, but I was not on CC, so I missed this email.
On Fri, Nov 17, 2023 at 2:41 PM juzhe.zh...@rivai.ai
wrote:
>
> Ok. I just read the theadvector extension.
>
> https://github.com/T-head-Semi/thead-extension-spec/blob/master/xtheadvector.adoc
>
> Theadvector is not custom extension. Just a uarch to disable some of the
> RVV1.0 extension
> Theadvector can be considered as subextension of 'V' extension with disabling
> some of the
> instructions and adding some new thead vector target load/store (This is
> another story).
>
> So, for disabling the instruction that theadvector doesn't support.
> You don't need to touch such many codes.
>
> Here is a much simpler approach to do (I think it's definitely working):
> 1. Don't change any codes in vector.md and keep GCC generates ASM with "th."
> prefix.
> 2. Add !TARGET_THEADVECTOR into vector-iterator.md to disable the mode you
> don't want.
> For example , theadvector doesn't support fractional vector.
>
> Then it's pretty simple:
>
> RVVMF2SI "TARGET_VECTOR && !TARGET_THEADVECTOR".
>
> 3. Remove all the tests you add in this patch.
> 4. You can add theadvector specific load/store for example, th.vlb
> instructions they are allowed.
> 5. Modify binutils, and make th.vmulh.vv as the pseudo instruction of vmulh.vv
> 6. So with compile option "-S", you will still see ASM as "vmulh.vv". but
> with objdump, you will see th.vmulh.vv.
Yes, all these points sound reasonable, to minimize the patchset size.
I believe in point 1 you meant "without th. prefix".
I've added Jin Ma (who is the main author of the Binutils patchset) so
he is also aware
of the proposal to use pseudo instructions to avoid duplication in Binutils.
Thank you very much!
Christoph
>
> After this change, you can send V2, then I can continue to review on GCC-15.
>
> Thanks.
>
>
> juzhe.zh...@rivai.ai
>
>
> From: juzhe.zh...@rivai.ai
> Date: 2023-11-17 19:39
> To: gcc-patches
> CC: kito.cheng; kito.cheng; cooper.joshua; Robin Dapp; jeffreyalaw
> Subject: RISC-V: Support XTheadVector extensions
> 90% theadvector extension reusing current RVV 1.0 instructions patterns:
> Just change ASM, For example:
>
> @@ -2923,7 +2923,7 @@ (define_insn "*pred_mulh_scalar"
> (match_operand:VFULLI_D 3 "register_operand" "vr,vr, vr, vr")] VMULH)
>(match_operand:VFULLI_D 2 "vector_merge_operand" "vu, 0, vu, 0")))]
>"TARGET_VECTOR"
> - "vmulh.vx\t%0,%3,%z4%p1"
> + "%^vmulh.vx\t%0,%3,%z4%p1"
>[(set_attr "type" "vimul")
> (set_attr "mode" "")])
>
> + if (letter == '^')
> +{
> + if (TARGET_XTHEADVECTOR)
> + fputs ("th.", file);
> + return;
> +}
>
>
> For almost all patterns, you just simply append "th." in the ASM prefix.
> like change "vmulh.vv" -> "th.vmulh.vv"
>
> Almost all theadvector instructions are not new features, all same as RVV1.0.
> Why do you invent the such ISA doesn't include any features that RVV1.0
> doesn't satisfy ?
>
> I am not explicitly object this patch. But I should know the reason.
>
> Btw, stage 1 will close soon. So I will review this patch on GCC-15 as long
> as all other RISC-V maintainers agree.
>
>
>
> juzhe.zh...@rivai.ai
Re: Re: RISC-V: Support XTheadVector extensions
On Wed, Nov 22, 2023 at 2:52 PM 钟居哲 wrote: > > I am totally ok to approve theadvector on GCC-14 before stage 3 close > as long as it doesn't touch the current RVV codes too much and binutils > supports theadvector. > > I have provided the draft approach: > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637349.html > which turns out doesn't need to change any codes of vector.md. > I strongly suggest follow this draft. I can be actively review theadvector > during stage 3. > And hopefully can help you land theadvector on GCC-14. I see now two approaches: 1) Let GCC emit RVV instructions for XTheadVector for instructions that are in both 2) Use the ASM_OUTPUT_OPCODE hook to output "th." for these instructions No doubt, the ASM_OUTPUT_OPCODE hook approach is better than our format-string approach, but would 1) not be the even better solution? It would also mean, that not a single test case is required for these overlapping instructions (only a few tests that ensure that we don't emit RVV instructions that are not available in XTheadVector). Besides that, letting GCC emit RVV instructions for XTheadVector is a very clever idea, because it fully utilizes the fact that both extensions overlap to a huge degree. The ASM_OUTPUT_OPCODE approach could lead to an issue if we enable XTheadVector with any other vector extension, say Zvfoo. In this case the Zvfoo instructions will all be prefixed as well with "th.". I know that it is not likely to run into this problem (such a machine does not exist in real hardware), but it is possible to trigger this issue easily and approach 1) would not have this potential issue. Thanks, Christoph > > Thanks. > > ____ > juzhe.zh...@rivai.ai > > > From: Christoph Müllner > Date: 2023-11-22 18:07 > To: juzhe.zh...@rivai.ai > CC: gcc-patches; kito.cheng; Kito.cheng; cooper.joshua; Robin Dapp; > jeffreyalaw; Philipp Tomsich; Cooper Qu; Jin Ma; Nelson Chu > Subject: Re: RISC-V: Support XTheadVector extensions > Hi Juzhe, > > Sorry for the late reply, but I was not on CC, so I missed this email. > > On Fri, Nov 17, 2023 at 2:41 PM juzhe.zh...@rivai.ai > wrote: > > > > Ok. I just read the theadvector extension. > > > > https://github.com/T-head-Semi/thead-extension-spec/blob/master/xtheadvector.adoc > > > > Theadvector is not custom extension. Just a uarch to disable some of the > > RVV1.0 extension > > Theadvector can be considered as subextension of 'V' extension with > > disabling some of the > > instructions and adding some new thead vector target load/store (This is > > another story). > > > > So, for disabling the instruction that theadvector doesn't support. > > You don't need to touch such many codes. > > > > Here is a much simpler approach to do (I think it's definitely working): > > 1. Don't change any codes in vector.md and keep GCC generates ASM with > > "th." prefix. > > 2. Add !TARGET_THEADVECTOR into vector-iterator.md to disable the mode you > > don't want. > > For example , theadvector doesn't support fractional vector. > > > > Then it's pretty simple: > > > > RVVMF2SI "TARGET_VECTOR && !TARGET_THEADVECTOR". > > > > 3. Remove all the tests you add in this patch. > > 4. You can add theadvector specific load/store for example, th.vlb > > instructions they are allowed. > > 5. Modify binutils, and make th.vmulh.vv as the pseudo instruction of > > vmulh.vv > > 6. So with compile option "-S", you will still see ASM as "vmulh.vv". but > > with objdump, you will see th.vmulh.vv. > > Yes, all these points sound reasonable, to minimize the patchset size. > I believe in point 1 you meant "without th. prefix". > > I've added Jin Ma (who is the main author of the Binutils patchset) so > he is also aware > of the proposal to use pseudo instructions to avoid duplication in Binutils. > > Thank you very much! > Christoph > > > > > > After this change, you can send V2, then I can continue to review on GCC-15. > > > > Thanks. > > > > > > juzhe.zh...@rivai.ai > > > > > > From: juzhe.zh...@rivai.ai > > Date: 2023-11-17 19:39 > > To: gcc-patches > > CC: kito.cheng; kito.cheng; cooper.joshua; Robin Dapp; jeffreyalaw > > Subject: RISC-V: Support XTheadVector extensions > > 90% theadvector extension reusing current RVV 1.0 instructions patterns: > > Just change ASM, For example: > > > > @@ -2923,7 +2923,7 @@ (define_insn "*pred_mulh_
Re: RISC-V: Support XTheadVector extensions
On Wed, Nov 22, 2023 at 11:48 PM Kito Cheng wrote: > > I am less worry about the thead vector combined with other zv extension, > instead we should reject those combinations at all. > > My reason is thead vector is transitional products, they won't have any > further new products with that longer, also it's not compatible with all > other zv extension in theory, zv extension requires at least zve32x which is > subset of v1p0, and I don't think it's valid to use thead vector as > replacement required extension - it should just introduce another thead > vector extension instead. The "transitional products" argument is probably enough to add this restriction, so we will add this to the first patch of the series. Further, we'll implement approach 1 (emitting no "th." prefix for instructions in vector.md) with an additional patch on top, which implements the ASM_OUTPUT_OPCODE hook (with a comment that clarifies why "ptr[0] == 'v'" is sufficient there). So the decision about this can be postponed and we can focus on the rest of the patchset as Jeff suggested. Thanks for the inputs! > > > > Jeff Law 於 2023年11月23日 週四 06:27 寫道： >> >> >> >> On 11/22/23 07:24, Christoph Müllner wrote: >> > On Wed, Nov 22, 2023 at 2:52 PM 钟居哲 wrote: >> >> >> >> I am totally ok to approve theadvector on GCC-14 before stage 3 close >> >> as long as it doesn't touch the current RVV codes too much and binutils >> >> supports theadvector. >> >> >> >> I have provided the draft approach: >> >> https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637349.html >> >> which turns out doesn't need to change any codes of vector.md. >> >> I strongly suggest follow this draft. I can be actively review >> >> theadvector during stage 3. >> >> And hopefully can help you land theadvector on GCC-14. >> > >> > I see now two approaches: >> > 1) Let GCC emit RVV instructions for XTheadVector for instructions >> > that are in both >> > 2) Use the ASM_OUTPUT_OPCODE hook to output "th." for these instructions >> > >> > No doubt, the ASM_OUTPUT_OPCODE hook approach is better than our >> > format-string approach, but would 1) not be the even better >> > solution? It would also mean, that not a single test case is required >> > for these overlapping instructions (only a few tests that ensure that >> > we don't emit RVV instructions that are not available in >> > XTheadVector). Besides that, letting GCC emit RVV instructions for >> > XTheadVector is a very clever idea, because it fully utilizes the >> > fact that both extensions overlap to a huge degree. >> > >> > The ASM_OUTPUT_OPCODE approach could lead to an issue if we enable >> XTheadVector >> > with any other vector extension, say Zvfoo. In this case the Zvfoo >> > instructions will all be prefixed as well with "th.". I know that it >> > is not likely to run into this problem (such a machine does not exist >> > in real hardware), but it is possible to trigger this issue easily >> > and approach 1) would not have this potential issue. >> I'm not a big fan of the ASM_OUTPUT_OPCODE approach.While it is >> simple, I worry a bit about it from a long term maintenance standpoint. >> As you note we could well end up at some point with an extension that >> has an mnenomic starting with "v" that would blow up. But I certainly >> see the appeal of such a simple test to support thead vector. >> >> Given there are at least 3 approaches that can fix that problem (%^, >> assembler dialect or ASM_OUTPUT_OPCODE), maybe we could set that >> discussion aside in the immediate term and see if there are other issues >> that are potentially more substantial. >> >> >> >> >> -- >> >> >> >> More generally, I think I need to soften my prior statement about >> deferring this to gcc-15. This code was submitted in time for the >> gcc-14 deadline, so it should be evaluated just like we do anything else >> that makes the deadline. There are various criteria we use to evaluate >> if something should get integrated and we should just work through this >> series like we always do and not treat it specially in any way. >> >> >> jeff
Re: [PATCH] Add C intrinsics for scalar crypto extension
On Mon, Nov 27, 2023 at 9:36 AM Liao Shihua wrote:
>
> This patch add C intrinsics for scalar crypto extension.
> Because of riscv-c-api
> (https://github.com/riscv-non-isa/riscv-c-api-doc/pull/44/files) includes
> zbkb/zbkc/zbkx's
> intrinsics in bit manipulation extension, this patch only support zkn*/zks*'s
> intrinsics.
Thanks for working on this!
Looking forward to seeing the second patch (covering bitmanip) soon as well!
A couple of comments can be found below.
>
> gcc/ChangeLog:
>
> * config.gcc: Add riscv_crypto.h
> * config/riscv/riscv_crypto.h: New file.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/zknd32.c: Use intrinsics instead of builtins.
> * gcc.target/riscv/zknd64.c: Likewise.
> * gcc.target/riscv/zkne32.c: Likewise.
> * gcc.target/riscv/zkne64.c: Likewise.
> * gcc.target/riscv/zknh-sha256-32.c: Likewise.
> * gcc.target/riscv/zknh-sha256-64.c: Likewise.
> * gcc.target/riscv/zknh-sha512-32.c: Likewise.
> * gcc.target/riscv/zknh-sha512-64.c: Likewise.
> * gcc.target/riscv/zksed32.c: Likewise.
> * gcc.target/riscv/zksed64.c: Likewise.
> * gcc.target/riscv/zksh32.c: Likewise.
> * gcc.target/riscv/zksh64.c: Likewise.
>
> ---
> gcc/config.gcc| 2 +-
> gcc/config/riscv/riscv_crypto.h | 219 ++
> gcc/testsuite/gcc.target/riscv/zknd32.c | 6 +-
> gcc/testsuite/gcc.target/riscv/zknd64.c | 12 +-
> gcc/testsuite/gcc.target/riscv/zkne32.c | 6 +-
> gcc/testsuite/gcc.target/riscv/zkne64.c | 10 +-
> .../gcc.target/riscv/zknh-sha256-32.c | 22 +-
> .../gcc.target/riscv/zknh-sha256-64.c | 10 +-
> .../gcc.target/riscv/zknh-sha512-32.c | 14 +-
> .../gcc.target/riscv/zknh-sha512-64.c | 10 +-
> gcc/testsuite/gcc.target/riscv/zksed32.c | 6 +-
> gcc/testsuite/gcc.target/riscv/zksed64.c | 6 +-
> gcc/testsuite/gcc.target/riscv/zksh32.c | 6 +-
> gcc/testsuite/gcc.target/riscv/zksh64.c | 6 +-
> 14 files changed, 288 insertions(+), 47 deletions(-)
> create mode 100644 gcc/config/riscv/riscv_crypto.h
>
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index b88591b6fd8..d67fe8b6a6f 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -548,7 +548,7 @@ riscv*)
> extra_objs="${extra_objs} riscv-vector-builtins.o
> riscv-vector-builtins-shapes.o riscv-vector-builtins-bases.o"
> extra_objs="${extra_objs} thead.o riscv-target-attr.o"
> d_target_objs="riscv-d.o"
> - extra_headers="riscv_vector.h"
> + extra_headers="riscv_vector.h riscv_crypto.h"
> target_gtfiles="$target_gtfiles
> \$(srcdir)/config/riscv/riscv-vector-builtins.cc"
> target_gtfiles="$target_gtfiles
> \$(srcdir)/config/riscv/riscv-vector-builtins.h"
> ;;
> diff --git a/gcc/config/riscv/riscv_crypto.h b/gcc/config/riscv/riscv_crypto.h
> new file mode 100644
> index 000..149c1132e10
> --- /dev/null
> +++ b/gcc/config/riscv/riscv_crypto.h
> @@ -0,0 +1,219 @@
> +/* RISC-V 'K' Extension intrinsics include file.
> + Copyright (C) 2023 Free Software Foundation, Inc.
> +
> + This file is part of GCC.
> +
> + GCC is free software; you can redistribute it and/or modify it
> + under the terms of the GNU General Public License as published
> + by the Free Software Foundation; either version 3, or (at your
> + option) any later version.
> +
> + GCC is distributed in the hope that it will be useful, but WITHOUT
> + ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
> + or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
> + License for more details.
> +
> + Under Section 7 of GPL version 3, you are granted additional
> + permissions described in the GCC Runtime Library Exception, version
> + 3.1, as published by the Free Software Foundation.
> +
> + You should have received a copy of the GNU General Public License and
> + a copy of the GCC Runtime Library Exception along with this program;
> + see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
> +
Re: [PATCH] Add C intrinsics for scalar crypto extension
On Wed, Nov 29, 2023 at 5:49 PM Liao Shihua wrote:
>
>
> 在 2023/11/29 23:03, Christoph Müllner 写道:
>
> On Mon, Nov 27, 2023 at 9:36 AM Liao Shihua wrote:
>
> This patch add C intrinsics for scalar crypto extension.
> Because of riscv-c-api
> (https://github.com/riscv-non-isa/riscv-c-api-doc/pull/44/files) includes
> zbkb/zbkc/zbkx's
> intrinsics in bit manipulation extension, this patch only support zkn*/zks*'s
> intrinsics.
>
> Thanks for working on this!
> Looking forward to seeing the second patch (covering bitmanip) soon as well!
> A couple of comments can be found below.
>
>
> Thanks for your comments, Christoph. Typos will be corrected in the next
> patch.
>
> The implementation of intrinsic is belonged to the implementation in the
> LLVM.(It does look a little strange)
>
> I will unify the implementation method in the next patch.
>
>
>
> gcc/ChangeLog:
>
> * config.gcc: Add riscv_crypto.h
> * config/riscv/riscv_crypto.h: New file.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/zknd32.c: Use intrinsics instead of builtins.
> * gcc.target/riscv/zknd64.c: Likewise.
> * gcc.target/riscv/zkne32.c: Likewise.
> * gcc.target/riscv/zkne64.c: Likewise.
> * gcc.target/riscv/zknh-sha256-32.c: Likewise.
> * gcc.target/riscv/zknh-sha256-64.c: Likewise.
> * gcc.target/riscv/zknh-sha512-32.c: Likewise.
> * gcc.target/riscv/zknh-sha512-64.c: Likewise.
> * gcc.target/riscv/zksed32.c: Likewise.
> * gcc.target/riscv/zksed64.c: Likewise.
> * gcc.target/riscv/zksh32.c: Likewise.
> * gcc.target/riscv/zksh64.c: Likewise.
>
> ---
> gcc/config.gcc| 2 +-
> gcc/config/riscv/riscv_crypto.h | 219 ++
> gcc/testsuite/gcc.target/riscv/zknd32.c | 6 +-
> gcc/testsuite/gcc.target/riscv/zknd64.c | 12 +-
> gcc/testsuite/gcc.target/riscv/zkne32.c | 6 +-
> gcc/testsuite/gcc.target/riscv/zkne64.c | 10 +-
> .../gcc.target/riscv/zknh-sha256-32.c | 22 +-
> .../gcc.target/riscv/zknh-sha256-64.c | 10 +-
> .../gcc.target/riscv/zknh-sha512-32.c | 14 +-
> .../gcc.target/riscv/zknh-sha512-64.c | 10 +-
> gcc/testsuite/gcc.target/riscv/zksed32.c | 6 +-
> gcc/testsuite/gcc.target/riscv/zksed64.c | 6 +-
> gcc/testsuite/gcc.target/riscv/zksh32.c | 6 +-
> gcc/testsuite/gcc.target/riscv/zksh64.c | 6 +-
> 14 files changed, 288 insertions(+), 47 deletions(-)
> create mode 100644 gcc/config/riscv/riscv_crypto.h
>
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index b88591b6fd8..d67fe8b6a6f 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -548,7 +548,7 @@ riscv*)
> extra_objs="${extra_objs} riscv-vector-builtins.o
> riscv-vector-builtins-shapes.o riscv-vector-builtins-bases.o"
> extra_objs="${extra_objs} thead.o riscv-target-attr.o"
> d_target_objs="riscv-d.o"
> - extra_headers="riscv_vector.h"
> + extra_headers="riscv_vector.h riscv_crypto.h"
> target_gtfiles="$target_gtfiles
> \$(srcdir)/config/riscv/riscv-vector-builtins.cc"
> target_gtfiles="$target_gtfiles
> \$(srcdir)/config/riscv/riscv-vector-builtins.h"
> ;;
> diff --git a/gcc/config/riscv/riscv_crypto.h b/gcc/config/riscv/riscv_crypto.h
> new file mode 100644
> index 000..149c1132e10
> --- /dev/null
> +++ b/gcc/config/riscv/riscv_crypto.h
> @@ -0,0 +1,219 @@
> +/* RISC-V 'K' Extension intrinsics include file.
> + Copyright (C) 2023 Free Software Foundation, Inc.
> +
> + This file is part of GCC.
> +
> + GCC is free software; you can redistribute it and/or modify it
> + under the terms of the GNU General Public License as published
> + by the Free Software Foundation; either version 3, or (at your
> + option) any later version.
> +
> + GCC is distributed in the hope that it will be useful, but WITHOUT
> + ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
> + or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
> + License for more details.
> +
> + Under Section 7 of GPL version 3, you are granted additional
> + permissions described in the GCC Runtime Library Exception, version
> + 3.1, as published by the Free Software Foundation.
> +
> + You should have received a copy of the GNU General Public License and
> + a copy of the GCC Runtime Library Exception along with this program;
> + see the files COPYING3 and COPYING.RUNTIME respectively. If not, se
Re: [RFC PATCH] RISC-V: Remove f{r,s}flags builtins
On Wed, Nov 29, 2023 at 8:24 PM Patrick O'Neill wrote: > > Hi Christoph, > > The precommit-ci is seeing a large number of ICE segmentation faults as a > result of this patch: > https://github.com/ewlu/gcc-precommit-ci/issues/796#issuecomment-1831853523 > > The failures aren't in riscv.exp testsuite files so that's likely why you > didn't run into them in your testing. Oh, I see. Then keeping things like they are is probably the best idea. Sorry for the noise! BR Christoph > > Debug log: > > /home/runner/work/gcc-precommit-ci/gcc-precommit-ci/riscv-gnu-toolchain/gcc/gcc/testsuite/gcc.dg/c11-atomic-2.c:110:3: > internal compiler error: Segmentation fault > 0x133afb3 crash_signal > ../../../gcc/gcc/toplev.cc:316 > 0x1678d1f contains_struct_check(tree_node*, tree_node_structure_enum, char > const*, int, char const*) > ../../../gcc/gcc/tree.h:3747 > 0x1678d1f build_call_expr_loc_array(unsigned int, tree_node*, int, > tree_node**) > ../../../gcc/gcc/tree.cc:10815 > 0x1679043 build_call_expr(tree_node*, int, ...) > ../../../gcc/gcc/tree.cc:10865 > 0x17f816e riscv_atomic_assign_expand_fenv(tree_node**, tree_node**, > tree_node**) > ../../../gcc/gcc/config/riscv/riscv-builtins.cc:420 > 0xc5209b build_atomic_assign > ../../../gcc/gcc/c/c-typeck.cc:4289 > 0xc60a47 build_modify_expr(unsigned int, tree_node*, tree_node*, tree_code, > unsigned int, tree_node*, tree_node*) > ../../../gcc/gcc/c/c-typeck.cc:6406 > 0xc85a61 c_parser_expr_no_commas > ../../../gcc/gcc/c/c-parser.cc:9112 > 0xc85db1 c_parser_expression > ../../../gcc/gcc/c/c-parser.cc:12725 > 0xc862bb c_parser_expression_conv > ../../../gcc/gcc/c/c-parser.cc:12765 > 0xca3607 c_parser_statement_after_labels > ../../../gcc/gcc/c/c-parser.cc:7755 > 0xc9f27e c_parser_compound_statement_nostart > ../../../gcc/gcc/c/c-parser.cc:7242 > 0xc9f804 c_parser_compound_statement > ../../../gcc/gcc/c/c-parser.cc:6527 > 0xca359c c_parser_statement_after_labels > ../../../gcc/gcc/c/c-parser.cc:7590 > 0xca5713 c_parser_statement > ../../../gcc/gcc/c/c-parser.cc:7561 > 0xca5713 c_parser_c99_block_statement > ../../../gcc/gcc/c/c-parser.cc:7820 > 0xca6a2c c_parser_do_statement > ../../../gcc/gcc/c/c-parser.cc:8194 > 0xca3d51 c_parser_statement_after_labels > ../../../gcc/gcc/c/c-parser.cc:7605 > 0xc9f27e c_parser_compound_statement_nostart > ../../../gcc/gcc/c/c-parser.cc:7242 > 0xc9f804 c_parser_compound_statement > ../../../gcc/gcc/c/c-parser.cc:6527 > Please submit a full bug report, with preprocessed source (by using > -freport-bug). > Please include the complete backtrace with any bug report. > See <https://gcc.gnu.org/bugs/> for instructions. > compiler exited with status 1 > FAIL: gcc.dg/c11-atomic-2.c (internal compiler error: Segmentation fault) > > Let me know if you need any additional info/investigation from me. > > Thanks, > Patrick > > On 11/29/23 03:49, Christoph Muellner wrote: > > From: Christoph Müllner > > We have two builtins which are undocumented and have no known users. > Further, they don't exist in LLVM (so are no portable). > This means they are in an unclear state of being supported or not. > Let's remove them get them out of this undecided state. > > A discussion about making these builtins available in all > compilers was held many years ago with the decision to > not document them in the RISC-V C API documentation: > https://github.com/riscv-non-isa/riscv-c-api-doc/pull/3 > > This is an RFC patch as this breaks existing code that uses > these builtins, even if we don't know if such code exists. > > An alternative to this patch would be to document them > in gcc/doc/extend.texi (like has been done with __builtin_riscv_pause) > and put them into a supported state. > > This patch removes two tests for these builtins. > A test of this patch did not trigger any regressions in riscv.exp. > > Signed-off-by: Christoph Müllner > > gcc/ChangeLog: > > * config/riscv/riscv-builtins.cc: Remove the builtins > __builtin_riscv_frflags and __builtin_riscv_fsflags. > > gcc/testsuite/ChangeLog: > > * g++.target/riscv/frflags.C: Removed. > * gcc.target/riscv/fsflags.c: Removed. > --- > gcc/config/riscv/riscv-builtins.cc | 2 -- > gcc/testsuite/g++.target/riscv/frflags.C | 7 --- > gcc/testsuite/gcc.target/riscv/fsflags.c | 16 > 3 files changed, 25 deletions(-) > delete mode 100644 gcc/testsuite/g++.target/riscv/frflags.C > delete mode 100644 gcc/testsuite/gcc.target/riscv/fsflags.c > > diff --git a/gcc/config/riscv/riscv-builtins.cc > b/gcc/config/riscv/riscv-builtins.cc > index fc3976f3ba1..1655492b246 100644 > --- a/gcc/config/ris
[PATCH 1/6] RISC-V: testsuite: Properly gate LTO tests
There are two test cases with the following skip directive:
dg-skip-if "" { *-*-* } { "-flto -fno-fat-lto-objects" }
This reads as: skip if both '-flto' and '-fno-fat-lto-objects'
are present. This is not the case if only '-flto' is present.
Since both tests depend on instruction sequences (one does
check-function-bodies the other tests for an assembler error
message), they won't work reliably with fat LTO objects.
Let's change the skip line to gate the test on '-flto'
to avoid failing tests like this:
FAIL: gcc.target/riscv/interrupt-misaligned.c -O2 -flto
check-function-bodies interrupt
FAIL: gcc.target/riscv/interrupt-misaligned.c -O2 -flto -flto-partition=none
check-function-bodies interrupt
FAIL: gcc.target/riscv/pr93202.c -O2 -flto (test for errors, line 10)
FAIL: gcc.target/riscv/pr93202.c -O2 -flto (test for errors, line 9)
FAIL: gcc.target/riscv/pr93202.c -O2 -flto -flto-partition=none (test for
errors, line 10)
FAIL: gcc.target/riscv/pr93202.c -O2 -flto -flto-partition=none (test for
errors, line 9)
gcc/testsuite/ChangeLog:
* gcc.target/riscv/interrupt-misaligned.c: Remove
"-fno-fat-lto-objects" from skip condition.
* gcc.target/riscv/pr93202.c: Likewise.
Signed-off-by: Christoph Müllner
---
gcc/testsuite/gcc.target/riscv/interrupt-misaligned.c | 2 +-
gcc/testsuite/gcc.target/riscv/pr93202.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.target/riscv/interrupt-misaligned.c
b/gcc/testsuite/gcc.target/riscv/interrupt-misaligned.c
index b5f8e6c2bbef..912f180e4d65 100644
--- a/gcc/testsuite/gcc.target/riscv/interrupt-misaligned.c
+++ b/gcc/testsuite/gcc.target/riscv/interrupt-misaligned.c
@@ -1,6 +1,6 @@
/* { dg-do compile } */
/* { dg-options "-O2 -march=rv64gc -mabi=lp64d -fno-schedule-insns
-fno-schedule-insns2" } */
-/* { dg-skip-if "" { *-*-* } { "-flto -fno-fat-lto-objects" } } */
+/* { dg-skip-if "" { *-*-* } { "-flto" } } */
/* Make sure no stack offset are misaligned.
** interrupt:
diff --git a/gcc/testsuite/gcc.target/riscv/pr93202.c
b/gcc/testsuite/gcc.target/riscv/pr93202.c
index 5501191ea52c..5de003fac421 100644
--- a/gcc/testsuite/gcc.target/riscv/pr93202.c
+++ b/gcc/testsuite/gcc.target/riscv/pr93202.c
@@ -1,7 +1,7 @@
/* PR inline-asm/93202 */
/* { dg-do compile { target fpic } } */
/* { dg-options "-fpic" } */
-/* { dg-skip-if "" { *-*-* } { "-flto -fno-fat-lto-objects" } } */
+/* { dg-skip-if "" { *-*-* } { "-flto" } } */
void
foo (void)
--
2.45.2
[PATCH 2/6] RISC-V: Deduplicate arch subset list processing
We have a code duplication in riscv_set_arch_by_subset_list() and
riscv_parse_arch_string(), where the latter function parses an ISA string
into a subset_list before doing the same as the former function.
riscv_parse_arch_string() is used to process command line options and
riscv_set_arch_by_subset_list() processes target attributes.
So, it is obvious that both functions should do the same.
Let's deduplicate the code to enforce this.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_set_arch_by_subset_list):
Fix overlong line.
(riscv_parse_arch_string): Replace duplicated code by a call to
riscv_set_arch_by_subset_list.
Signed-off-by: Christoph Müllner
---
gcc/common/config/riscv/riscv-common.cc | 32 +
1 file changed, 6 insertions(+), 26 deletions(-)
diff --git a/gcc/common/config/riscv/riscv-common.cc
b/gcc/common/config/riscv/riscv-common.cc
index 16bdb3fd2259..dfe960e51293 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -1818,7 +1818,8 @@ riscv_set_arch_by_subset_list (riscv_subset_list
*subset_list,
else if (subset_list->xlen () == 64)
opts->x_target_flags |= MASK_64BIT;
- for (arch_ext_flag_tab = &riscv_ext_flag_table[0];
arch_ext_flag_tab->ext;
+ for (arch_ext_flag_tab = &riscv_ext_flag_table[0];
+ arch_ext_flag_tab->ext;
++arch_ext_flag_tab)
{
if (subset_list->lookup (arch_ext_flag_tab->ext))
@@ -1842,30 +1843,6 @@ riscv_parse_arch_string (const char *isa,
if (!subset_list)
return;
- if (opts)
-{
- const riscv_ext_flag_table_t *arch_ext_flag_tab;
- /* Clean up target flags before we set. */
- for (arch_ext_flag_tab = &riscv_ext_flag_table[0];
- arch_ext_flag_tab->ext;
- ++arch_ext_flag_tab)
- opts->*arch_ext_flag_tab->var_ref &= ~arch_ext_flag_tab->mask;
-
- if (subset_list->xlen () == 32)
- opts->x_target_flags &= ~MASK_64BIT;
- else if (subset_list->xlen () == 64)
- opts->x_target_flags |= MASK_64BIT;
-
-
- for (arch_ext_flag_tab = &riscv_ext_flag_table[0];
- arch_ext_flag_tab->ext;
- ++arch_ext_flag_tab)
- {
- if (subset_list->lookup (arch_ext_flag_tab->ext))
- opts->*arch_ext_flag_tab->var_ref |= arch_ext_flag_tab->mask;
- }
-}
-
/* Avoid double delete if current_subset_list equals cmdline_subset_list. */
if (current_subset_list && current_subset_list != cmdline_subset_list)
delete current_subset_list;
@@ -1873,7 +1850,10 @@ riscv_parse_arch_string (const char *isa,
if (cmdline_subset_list)
delete cmdline_subset_list;
- current_subset_list = cmdline_subset_list = subset_list;
+ cmdline_subset_list = subset_list;
+ /* current_subset_list is set in the call below. */
+
+ riscv_set_arch_by_subset_list (subset_list, opts);
}
/* Return the riscv_cpu_info entry for CPU, NULL if not found. */
--
2.45.2
[PATCH 0/6] RISC-V: Rewrite target arch attribute handling
As reported in PR 115554 and PR 115562, the current RISC-V target attribute handling code suffers from ICEs for legal inputs. An analysis of the code revealed deficits in the way target arch attributes are stored in the backend. This series attempts to address these issues. The first four commit are independent code cleanups that don't introduce new functionality. Patch five is the rewrite of the code that stores arch attributes. And patch six ensures enabled extensions may be added via arch attributes, giving them an accumulation semantics. Each patch of the series has been regression tested (rv32+rv64). Further, the series has been build with --enable-werror-always to ensure no new build warnings. Note, that patch 5 introduces six regression, which are addressed by patch 6 (the commit message lists them). This rewrite was motivited by issues that were discovered while analysing a build issue with a patchset to introduce optimized string processing routines for RISC-V in glibc. See also: https://sourceware.org/pipermail/libc-alpha/2024-June/157627.html Christoph Müllner (6): RISC-V: testsuite: Properly gate LTO tests RISC-V: Deduplicate arch subset list processing RISC-V: Attribute parser: Use alloca() instead of new + std::unique_ptr RISC-V: Fix comment/naming in attribute parsing code RISC-V: Rewrite target attribute handling RISC-V: Allow adding enabled extension via target arch attributes gcc/common/config/riscv/riscv-common.cc | 160 +++--- gcc/config/riscv/riscv-c.cc | 2 +- gcc/config/riscv/riscv-subset.h | 9 +- gcc/config/riscv/riscv-target-attr.cc | 122 +++-- gcc/config/riscv/riscv.cc | 22 ++- gcc/config/riscv/riscv.opt| 2 +- .../gcc.target/riscv/interrupt-misaligned.c | 2 +- gcc/testsuite/gcc.target/riscv/pr115554.c | 11 ++ gcc/testsuite/gcc.target/riscv/pr115562.c | 25 +++ gcc/testsuite/gcc.target/riscv/pr93202.c | 2 +- .../gcc.target/riscv/target-attr-01.c | 16 +- .../gcc.target/riscv/target-attr-02.c | 16 +- .../gcc.target/riscv/target-attr-03.c | 11 +- .../gcc.target/riscv/target-attr-04.c | 11 +- .../gcc.target/riscv/target-attr-05.c | 10 +- .../gcc.target/riscv/target-attr-06.c | 11 +- .../gcc.target/riscv/target-attr-07.c | 10 +- .../gcc.target/riscv/target-attr-08.c | 20 +++ .../gcc.target/riscv/target-attr-09.c | 19 +++ .../gcc.target/riscv/target-attr-10.c | 19 +++ .../gcc.target/riscv/target-attr-11.c | 22 +++ .../gcc.target/riscv/target-attr-12.c | 21 +++ .../gcc.target/riscv/target-attr-13.c | 21 +++ .../gcc.target/riscv/target-attr-14.c | 42 + .../gcc.target/riscv/target-attr-15.c | 42 + .../gcc.target/riscv/target-attr-16.c | 26 +++ 26 files changed, 428 insertions(+), 246 deletions(-) create mode 100644 gcc/testsuite/gcc.target/riscv/pr115554.c create mode 100644 gcc/testsuite/gcc.target/riscv/pr115562.c create mode 100644 gcc/testsuite/gcc.target/riscv/target-attr-08.c create mode 100644 gcc/testsuite/gcc.target/riscv/target-attr-09.c create mode 100644 gcc/testsuite/gcc.target/riscv/target-attr-10.c create mode 100644 gcc/testsuite/gcc.target/riscv/target-attr-11.c create mode 100644 gcc/testsuite/gcc.target/riscv/target-attr-12.c create mode 100644 gcc/testsuite/gcc.target/riscv/target-attr-13.c create mode 100644 gcc/testsuite/gcc.target/riscv/target-attr-14.c create mode 100644 gcc/testsuite/gcc.target/riscv/target-attr-15.c create mode 100644 gcc/testsuite/gcc.target/riscv/target-attr-16.c -- 2.45.2
[PATCH 4/6] RISC-V: Fix comment/naming in attribute parsing code
Function target attributes have to be separated by semi-colons.
Let's fix the comment and variable naming to better explain what
the code does.
gcc/ChangeLog:
* config/riscv/riscv-target-attr.cc (riscv_process_target_attr):
Fix comments and variable names.
Signed-off-by: Christoph Müllner
---
gcc/config/riscv/riscv-target-attr.cc | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/config/riscv/riscv-target-attr.cc
b/gcc/config/riscv/riscv-target-attr.cc
index e59cc53f23c6..3d7753f64574 100644
--- a/gcc/config/riscv/riscv-target-attr.cc
+++ b/gcc/config/riscv/riscv-target-attr.cc
@@ -335,11 +335,11 @@ riscv_process_target_attr (tree fndecl, tree args,
location_t loc,
char *str_to_check = (char *) alloca (len + 1);
strcpy (str_to_check, TREE_STRING_POINTER (args));
- /* Used to catch empty spaces between commas i.e.
+ /* Used to catch empty spaces between semi-colons i.e.
attribute ((target ("attr1;;attr2"))). */
- unsigned int num_commas = num_occurences_in_str (';', str_to_check);
+ unsigned int num_semicolons = num_occurences_in_str (';', str_to_check);
- /* Handle multiple target attributes separated by ','. */
+ /* Handle multiple target attributes separated by ';'. */
char *token = strtok_r (str_to_check, ";", &str_to_check);
riscv_target_attr_parser attr_parser (loc);
@@ -351,7 +351,7 @@ riscv_process_target_attr (tree fndecl, tree args,
location_t loc,
token = strtok_r (NULL, ";", &str_to_check);
}
- if (num_attrs != num_commas + 1)
+ if (num_attrs != num_semicolons + 1)
{
error_at (loc, "malformed % attribute",
TREE_STRING_POINTER (args));
--
2.45.2
[PATCH 3/6] RISC-V: Attribute parser: Use alloca() instead of new + std::unique_ptr
Allocating an object on the heap with new, wrapping it in a
std::unique_ptr and finally getting the buffer via buf.get()
is a correct way to allocate a buffer that is automatically
freed on return. However, a simple invocation of alloca()
does the same with less overhead.
gcc/ChangeLog:
* config/riscv/riscv-target-attr.cc
(riscv_target_attr_parser::parse_arch):
Replace new + std::unique_ptr by alloca().
(riscv_process_one_target_attr): Likewise.
(riscv_process_target_attr): Likewise.
Signed-off-by: Christoph Müllner
---
gcc/config/riscv/riscv-target-attr.cc | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/gcc/config/riscv/riscv-target-attr.cc
b/gcc/config/riscv/riscv-target-attr.cc
index 19eb7b06d548..e59cc53f23c6 100644
--- a/gcc/config/riscv/riscv-target-attr.cc
+++ b/gcc/config/riscv/riscv-target-attr.cc
@@ -109,8 +109,7 @@ riscv_target_attr_parser::parse_arch (const char *str)
{
/* Parsing the extension list like "+[,+]*". */
size_t len = strlen (str);
- std::unique_ptr buf (new char[len+1]);
- char *str_to_check = buf.get ();
+ char *str_to_check = (char *) alloca (len + 1);
strcpy (str_to_check, str);
const char *token = strtok_r (str_to_check, ",", &str_to_check);
m_subset_list = riscv_cmdline_subset_list ()->clone ();
@@ -247,8 +246,7 @@ riscv_process_one_target_attr (char *arg_str,
return false;
}
- std::unique_ptr buf (new char[len+1]);
- char *str_to_check = buf.get();
+ char *str_to_check = (char *) alloca (len + 1);
strcpy (str_to_check, arg_str);
char *arg = strchr (str_to_check, '=');
@@ -334,8 +332,7 @@ riscv_process_target_attr (tree fndecl, tree args,
location_t loc,
return false;
}
- std::unique_ptr buf (new char[len+1]);
- char *str_to_check = buf.get ();
+ char *str_to_check = (char *) alloca (len + 1);
strcpy (str_to_check, TREE_STRING_POINTER (args));
/* Used to catch empty spaces between commas i.e.
--
2.45.2
[PATCH 5/6] RISC-V: Rewrite target attribute handling
* gcc.target/riscv/target-attr-07.c: Likewise.
* gcc.target/riscv/pr115554.c: New test.
* gcc.target/riscv/pr115562.c: New test.
* gcc.target/riscv/target-attr-08.c: New test.
* gcc.target/riscv/target-attr-09.c: New test.
* gcc.target/riscv/target-attr-10.c: New test.
* gcc.target/riscv/target-attr-11.c: New test.
* gcc.target/riscv/target-attr-12.c: New test.
* gcc.target/riscv/target-attr-13.c: New test.
* gcc.target/riscv/target-attr-14.c: New test.
* gcc.target/riscv/target-attr-15.c: New test.
Signed-off-by: Christoph Müllner
---
gcc/common/config/riscv/riscv-common.cc | 113 +-
gcc/config/riscv/riscv-c.cc | 2 +-
gcc/config/riscv/riscv-subset.h | 4 -
gcc/config/riscv/riscv-target-attr.cc | 102 +---
gcc/config/riscv/riscv.cc | 22 ++--
gcc/config/riscv/riscv.opt| 2 +-
gcc/testsuite/gcc.target/riscv/pr115554.c | 13 ++
gcc/testsuite/gcc.target/riscv/pr115562.c | 25
.../gcc.target/riscv/target-attr-01.c | 16 ++-
.../gcc.target/riscv/target-attr-02.c | 16 ++-
.../gcc.target/riscv/target-attr-03.c | 11 +-
.../gcc.target/riscv/target-attr-04.c | 11 +-
.../gcc.target/riscv/target-attr-05.c | 10 +-
.../gcc.target/riscv/target-attr-06.c | 11 +-
.../gcc.target/riscv/target-attr-07.c | 10 +-
.../gcc.target/riscv/target-attr-08.c | 20
.../gcc.target/riscv/target-attr-09.c | 19 +++
.../gcc.target/riscv/target-attr-10.c | 19 +++
.../gcc.target/riscv/target-attr-11.c | 22
.../gcc.target/riscv/target-attr-12.c | 21
.../gcc.target/riscv/target-attr-13.c | 21
.../gcc.target/riscv/target-attr-14.c | 42 +++
.../gcc.target/riscv/target-attr-15.c | 42 +++
23 files changed, 371 insertions(+), 203 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/riscv/pr115554.c
create mode 100644 gcc/testsuite/gcc.target/riscv/pr115562.c
create mode 100644 gcc/testsuite/gcc.target/riscv/target-attr-08.c
create mode 100644 gcc/testsuite/gcc.target/riscv/target-attr-09.c
create mode 100644 gcc/testsuite/gcc.target/riscv/target-attr-10.c
create mode 100644 gcc/testsuite/gcc.target/riscv/target-attr-11.c
create mode 100644 gcc/testsuite/gcc.target/riscv/target-attr-12.c
create mode 100644 gcc/testsuite/gcc.target/riscv/target-attr-13.c
create mode 100644 gcc/testsuite/gcc.target/riscv/target-attr-14.c
create mode 100644 gcc/testsuite/gcc.target/riscv/target-attr-15.c
diff --git a/gcc/common/config/riscv/riscv-common.cc
b/gcc/common/config/riscv/riscv-common.cc
index dfe960e51293..c215484c287b 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -438,110 +438,13 @@ static const char *riscv_supported_std_ext (void);
bool riscv_subset_list::parse_failed = false;
-static riscv_subset_list *current_subset_list = NULL;
-
static riscv_subset_list *cmdline_subset_list = NULL;
-struct riscv_func_target_info
-{
- tree fn_decl;
- std::string fn_target_name;
-
- riscv_func_target_info (const tree &decl, const std::string &target_name)
-: fn_decl (decl), fn_target_name (target_name)
- {
- }
-};
-
-struct riscv_func_target_hasher : nofree_ptr_hash
-{
- typedef tree compare_type;
-
- static hashval_t hash (value_type);
- static bool equal (value_type, const compare_type &);
-};
-
-static hash_table *func_target_table = NULL;
-
-static inline hashval_t riscv_func_decl_hash (tree fn_decl)
-{
- inchash::hash h;
-
- h.add_ptr (fn_decl);
-
- return h.end ();
-}
-
-inline hashval_t
-riscv_func_target_hasher::hash (value_type value)
-{
- return riscv_func_decl_hash (value->fn_decl);
-}
-
-inline bool
-riscv_func_target_hasher::equal (value_type value, const compare_type &key)
-{
- return value->fn_decl == key;
-}
-
-const riscv_subset_list *riscv_current_subset_list ()
-{
- return current_subset_list;
-}
-
-const riscv_subset_list * riscv_cmdline_subset_list ()
+const riscv_subset_list *riscv_cmdline_subset_list ()
{
return cmdline_subset_list;
}
-static inline void riscv_func_target_table_lazy_init ()
-{
- if (func_target_table != NULL)
-return;
-
- func_target_table = new hash_table (1023);
-}
-
-std::string * riscv_func_target_get (tree fn_decl)
-{
- riscv_func_target_table_lazy_init ();
-
- hashval_t hash = riscv_func_decl_hash (fn_decl);
- struct riscv_func_target_info *info
-= func_target_table->find_with_hash (fn_decl, hash);
-
- return info == NULL ? NULL : &info->fn_target_name;
-}
-
-void riscv_func_target_put (tree fn_decl, std::string fn_target_name)
-{
- riscv_func_target_table_lazy_init ();
-
- hashval_t hash = riscv_func_decl_hash (fn_decl);
- struct riscv_func_target_info **target_info_slot
-= func_targe
[PATCH 6/6] RISC-V: Allow adding enabled extension via target arch attributes
The set of enabled extensions can be extended via target arch function
attributes by listing each extension with a '+' prefix and a comma as
list separator. E.g.:
__attribute__((target("arch=+zba,+zbb"))) void foo();
The programmer intends to ensure that one or more extensions
are enabled when building the code. This is independent of the arch
string that is passed at build time via the -march= option.
Therefore, it is reasonable to allow enabling extensions via target arch
attributes, which have already been enabled via the -march= string.
The subset list code already supports such duplication for implied
extensions. This patch adds an interface so the subset list
parser can be switched into a mode where duplication is allowed.
This commit fixes the following regressed test cases:
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-39.c
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-42.c
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-43.c
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-44.c
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-45.c
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-46.c
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_subset_list::add):
Allow adding enabled extension if m_allow_adding_dup is set.
* config/riscv/riscv-subset.h: Add m_allow_adding_dup and setter.
* config/riscv/riscv-target-attr.cc
(riscv_target_attr_parser::parse_arch):
Allow adding enabled extensions.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr115554.c: Change expected fail to expected pass.
* gcc.target/riscv/target-attr-16.c: New test.
Signed-off-by: Christoph Müllner
---
gcc/common/config/riscv/riscv-common.cc | 17 +++-
gcc/config/riscv/riscv-subset.h | 5
gcc/config/riscv/riscv-target-attr.cc | 3 +++
gcc/testsuite/gcc.target/riscv/pr115554.c | 2 --
.../gcc.target/riscv/target-attr-16.c | 26 +++
5 files changed, 45 insertions(+), 8 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/riscv/target-attr-16.c
diff --git a/gcc/common/config/riscv/riscv-common.cc
b/gcc/common/config/riscv/riscv-common.cc
index c215484c287b..be4a87abee6d 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -677,12 +677,17 @@ riscv_subset_list::add (const char *subset, int
major_version,
ext->minor_version = minor_version;
}
else
- error_at (
- m_loc,
- "%<-march=%s%>: extension %qs appear more than one time",
- m_arch,
- subset);
-
+ {
+ /* The extension is already in the list. */
+ if (!m_allow_adding_dup
+ || ext->major_version != major_version
+ || ext->minor_version != minor_version)
+ error_at (
+ m_loc,
+ "%<-march=%s%>: extension %qs appear more than one time",
+ m_arch,
+ subset);
+ }
return;
}
else if (strlen (subset) == 1 && !standard_extensions_p (subset))
diff --git a/gcc/config/riscv/riscv-subset.h b/gcc/config/riscv/riscv-subset.h
index 256d28657460..c2d213c1734f 100644
--- a/gcc/config/riscv/riscv-subset.h
+++ b/gcc/config/riscv/riscv-subset.h
@@ -62,6 +62,9 @@ private:
/* X-len of m_arch. */
unsigned m_xlen;
+ /* Allow adding the same extension more than once. */
+ bool m_allow_adding_dup;
+
riscv_subset_list (const char *, location_t);
const char *parsing_subset_version (const char *, const char *, unsigned *,
@@ -106,6 +109,8 @@ public:
void set_loc (location_t);
+ void set_allow_adding_dup (bool v) { m_allow_adding_dup = v; }
+
void finalize ();
};
diff --git a/gcc/config/riscv/riscv-target-attr.cc
b/gcc/config/riscv/riscv-target-attr.cc
index 317806143949..57235c9c0a7e 100644
--- a/gcc/config/riscv/riscv-target-attr.cc
+++ b/gcc/config/riscv/riscv-target-attr.cc
@@ -109,6 +109,8 @@ riscv_target_attr_parser::parse_arch (const char *str)
? riscv_subset_list::parse (local_arch_str, m_loc)
: riscv_cmdline_subset_list ()->clone ();
m_subset_list->set_loc (m_loc);
+ m_subset_list->set_allow_adding_dup (true);
+
while (token)
{
if (token[0] != '+')
@@ -134,6 +136,7 @@ riscv_target_attr_parser::parse_arch (const char *str)
token = strtok_r (NULL, ",", &str_to_check);
}
+ m_subset_list->set_allow_adding_dup (false);
m_subset_list->finalize ();
return true;
}
diff --git a/gcc/testsuite/gcc.target/riscv/pr115554.c
b/gcc/testsuite/gcc.target/riscv/pr115554.c
index e7dcde6276fa..16d5f63aac0b 100644
--- a/gcc/testsuite/gcc.target/riscv/pr115554.c
+++ b/gcc/testsuite/gcc.target/ris
Re: [PATCH 3/6] RISC-V: Attribute parser: Use alloca() instead of new + std::unique_ptr
On Tue, Jul 9, 2024 at 3:01 PM Kito Cheng wrote:
>
> IIRC Jeff mentions that it may introduce buffer overflow if the input
> string is long enough.
The manpage states:
If the allocation causes stack overflow, program behavior is undefined.
This was considered reasonable for AArch64:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/aarch64/aarch64.cc;h=7f0cc47d0f071de9297068baa85c6d5fc4d7fa5b;hb=HEAD#l19408
So, my assumption was that it should be fine for RISC-V as well.
However, I won't insist on this patch.
>
> On Tue, Jul 9, 2024 at 8:48 PM Christoph Müllner
> wrote:
> >
> > Allocating an object on the heap with new, wrapping it in a
> > std::unique_ptr and finally getting the buffer via buf.get()
> > is a correct way to allocate a buffer that is automatically
> > freed on return. However, a simple invocation of alloca()
> > does the same with less overhead.
> >
> > gcc/ChangeLog:
> >
> > * config/riscv/riscv-target-attr.cc
> > (riscv_target_attr_parser::parse_arch):
> > Replace new + std::unique_ptr by alloca().
> > (riscv_process_one_target_attr): Likewise.
> > (riscv_process_target_attr): Likewise.
> >
> > Signed-off-by: Christoph Müllner
> > ---
> > gcc/config/riscv/riscv-target-attr.cc | 9 +++--
> > 1 file changed, 3 insertions(+), 6 deletions(-)
> >
> > diff --git a/gcc/config/riscv/riscv-target-attr.cc
> > b/gcc/config/riscv/riscv-target-attr.cc
> > index 19eb7b06d548..e59cc53f23c6 100644
> > --- a/gcc/config/riscv/riscv-target-attr.cc
> > +++ b/gcc/config/riscv/riscv-target-attr.cc
> > @@ -109,8 +109,7 @@ riscv_target_attr_parser::parse_arch (const char *str)
> > {
> >/* Parsing the extension list like "+[,+]*". */
> >size_t len = strlen (str);
> > - std::unique_ptr buf (new char[len+1]);
> > - char *str_to_check = buf.get ();
> > + char *str_to_check = (char *) alloca (len + 1);
> >strcpy (str_to_check, str);
> >const char *token = strtok_r (str_to_check, ",", &str_to_check);
> >m_subset_list = riscv_cmdline_subset_list ()->clone ();
> > @@ -247,8 +246,7 @@ riscv_process_one_target_attr (char *arg_str,
> >return false;
> > }
> >
> > - std::unique_ptr buf (new char[len+1]);
> > - char *str_to_check = buf.get();
> > + char *str_to_check = (char *) alloca (len + 1);
> >strcpy (str_to_check, arg_str);
> >
> >char *arg = strchr (str_to_check, '=');
> > @@ -334,8 +332,7 @@ riscv_process_target_attr (tree fndecl, tree args,
> > location_t loc,
> >return false;
> > }
> >
> > - std::unique_ptr buf (new char[len+1]);
> > - char *str_to_check = buf.get ();
> > + char *str_to_check = (char *) alloca (len + 1);
> >strcpy (str_to_check, TREE_STRING_POINTER (args));
> >
> >/* Used to catch empty spaces between commas i.e.
> > --
> > 2.45.2
> >
Re: [PATCH 5/6] RISC-V: Rewrite target attribute handling
On Mon, Jul 15, 2024 at 11:10 AM Kito Cheng wrote: > > LGTM, and could you backport this to the GCC 14 branch as well? Rebased, retested (multilib), fixed an issue related to Zca/Zcd and pushed. Should the GCC 14 backport be posted for review before pushing? Thanks, Christoph > > On Tue, Jul 9, 2024 at 8:50 PM Christoph Müllner > wrote: > > > > The target-arch attribute handling in RISC-V is only a few months old, > > but already saw a rewrite (9941f0295a14), which addressed an important > > issue. This rewrite introduced a hash table in the backend, which is > > used to keep track of target-arch attributes of all functions. > > The index of this hash table is the pointer to the function declaration > > object (fndecl). However, objects like these don't have the lifetime > > that is assumed here, which resulted in observing two fndecl objects > > with the same address for different objects (triggering the assertion > > in riscv_func_target_put() -- see also PR115562). > > > > This patch removes the hash table approach in favor of storing target > > specific options using the DECL_FUNCTION_SPECIFIC_TARGET() macro, which > > is also used by other backends and is specifically designed for this > > purpose (https://gcc.gnu.org/onlinedocs/gccint/Function-Properties.html). > > > > To have an accessible field in the target options, we need to > > adjust riscv.opt and introduce the field riscv_arch_string > > (for the already existing option '-march='). > > > > Using this macro allows to remove much code from riscv-common.cc, which > > controls access to the objects 'func_target_table' and > > 'current_subset_list'. > > > > One thing to mention is, that we had two subset lists: > > current_subset_list and cmdline_subset_list, with the latter being > > introduced recently for target attribute handling. > > This patch reduces them back to one (cmdline_subset_list) which > > contains the list of extensions that have been enabled by the command > > line arguments. > > > > Note that the patch keeps the existing behavior of rejecting > > duplications of extensions when added via the '+' operator in a function > > target attribute. E.g. "-march=rv64gc_zbb" and "arch=+zbb" will trigger > > an error (see pr115554.c). However, at the same time this patch breaks > > the acceptance of adding implied extensions, which causes the following > > six regressions (with the error "extension 'EXT' appear more than one > > time"): > > * gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-39.c > > * gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-42.c > > * gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-43.c > > * gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-44.c > > * gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-45.c > > * gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-46.c > > > > New tests were added to document the behavior and to ensure it won't > > regress. This patch did not show any regressions for rv32/rv64 > > and fixes the ICEs from PR115554 and PR115562. > > > > PR 115554 > > PR 115562 > > > > gcc/ChangeLog: > > > > * common/config/riscv/riscv-common.cc (struct > > riscv_func_target_info): > > Remove. > > (struct riscv_func_target_hasher): Likewise. > > (riscv_func_decl_hash): Likewise. > > (riscv_func_target_hasher::hash): Likewise. > > (riscv_func_target_hasher::equal): Likewise. > > (riscv_current_subset_list): Likewise. > > (riscv_cmdline_subset_list): Remove obsolete space. > > (riscv_func_target_table_lazy_init): Remove. > > (riscv_func_target_get): Likewise. > > (riscv_func_target_put): Likewise. > > (riscv_func_target_remove_and_destory): Likewise. > > (riscv_arch_str): Generate from cmdline_subset_list. > > (riscv_set_arch_by_subset_list): Don't set current_subset_list. > > (riscv_parse_arch_string): Remove current_subset_list. > > * config/riscv/riscv-c.cc (riscv_cpu_cpp_builtins): > > Get subset list via riscv_cmdline_subset_list(). > > * config/riscv/riscv-subset.h (riscv_current_subset_list): > > Remove prototype. > > (riscv_func_target_get): Likewise. > > (riscv_func_target_put): Likewise. > > (riscv_func_target_remove_and_destory): Likewise
Re: [PATCH 5/6] RISC-V: Rewrite target attribute handling
On Tue, Jul 16, 2024 at 4:45 AM Kito Cheng wrote: > > On Tue, Jul 16, 2024 at 1:09 AM Christoph Müllner > wrote: > > > > On Mon, Jul 15, 2024 at 11:10 AM Kito Cheng wrote: > > > > > > LGTM, and could you backport this to the GCC 14 branch as well? > > > > Rebased, retested (multilib), fixed an issue related to Zca/Zcd and pushed. > > > > Should the GCC 14 backport be posted for review before pushing? > > I guess the patch for GCC 14 may little different than this patch > series since Pan's rewrite isn't applied on that, > however I trust you will handle this well, so pre-approved for that :P The hashtable rewrite is on GCC 14: git branch -a --contains 9941f0295a14659e25260458efd2e46a68ad0342 [...] remotes/origin/master remotes/origin/releases/gcc-14 [...] So the backport to GCC 14 would include all patches of this series with the exception of the alloca() patch. Adjustments are just needed for some of the tests, because "rv64gc" expands to less instruction sets in GCC14 (no zaamo1p0_zalrsc1p0_zca1p0_zcd1p0). I've already cherry-picked, adjusted and successfully tested that and will push if that's ok. BTW, I accidentally pushed the alloca()-patch to master. But I reverted that as soon as I noticed my mistake. Apologies for that! > > but don't forget to send committed patches to the mailing list (with > [committed][GCC-14] prefix in the title), so that we know you are done > :) > > > > > > > > Thanks, > > Christoph > > > > > > > > On Tue, Jul 9, 2024 at 8:50 PM Christoph Müllner > > > wrote: > > > > > > > > The target-arch attribute handling in RISC-V is only a few months old, > > > > but already saw a rewrite (9941f0295a14), which addressed an important > > > > issue. This rewrite introduced a hash table in the backend, which is > > > > used to keep track of target-arch attributes of all functions. > > > > The index of this hash table is the pointer to the function declaration > > > > object (fndecl). However, objects like these don't have the lifetime > > > > that is assumed here, which resulted in observing two fndecl objects > > > > with the same address for different objects (triggering the assertion > > > > in riscv_func_target_put() -- see also PR115562). > > > > > > > > This patch removes the hash table approach in favor of storing target > > > > specific options using the DECL_FUNCTION_SPECIFIC_TARGET() macro, which > > > > is also used by other backends and is specifically designed for this > > > > purpose > > > > (https://gcc.gnu.org/onlinedocs/gccint/Function-Properties.html). > > > > > > > > To have an accessible field in the target options, we need to > > > > adjust riscv.opt and introduce the field riscv_arch_string > > > > (for the already existing option '-march='). > > > > > > > > Using this macro allows to remove much code from riscv-common.cc, which > > > > controls access to the objects 'func_target_table' and > > > > 'current_subset_list'. > > > > > > > > One thing to mention is, that we had two subset lists: > > > > current_subset_list and cmdline_subset_list, with the latter being > > > > introduced recently for target attribute handling. > > > > This patch reduces them back to one (cmdline_subset_list) which > > > > contains the list of extensions that have been enabled by the command > > > > line arguments. > > > > > > > > Note that the patch keeps the existing behavior of rejecting > > > > duplications of extensions when added via the '+' operator in a function > > > > target attribute. E.g. "-march=rv64gc_zbb" and "arch=+zbb" will trigger > > > > an error (see pr115554.c). However, at the same time this patch breaks > > > > the acceptance of adding implied extensions, which causes the following > > > > six regressions (with the error "extension 'EXT' appear more than one > > > > time"): > > > > * gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-39.c > > > > * gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-42.c > > > > * gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-43.c > > > > * gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-44.c > > > > * gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsi
[committed][GCC-14] RISC-V: testsuite: Properly gate LTO tests
There are two test cases with the following skip directive:
dg-skip-if "" { *-*-* } { "-flto -fno-fat-lto-objects" }
This reads as: skip if both '-flto' and '-fno-fat-lto-objects'
are present. This is not the case if only '-flto' is present.
Since both tests depend on instruction sequences (one does
check-function-bodies the other tests for an assembler error
message), they won't work reliably with fat LTO objects.
Let's change the skip line to gate the test on '-flto'
to avoid failing tests like this:
FAIL: gcc.target/riscv/interrupt-misaligned.c -O2 -flto
check-function-bodies interrupt
FAIL: gcc.target/riscv/interrupt-misaligned.c -O2 -flto -flto-partition=none
check-function-bodies interrupt
FAIL: gcc.target/riscv/pr93202.c -O2 -flto (test for errors, line 10)
FAIL: gcc.target/riscv/pr93202.c -O2 -flto (test for errors, line 9)
FAIL: gcc.target/riscv/pr93202.c -O2 -flto -flto-partition=none (test for
errors, line 10)
FAIL: gcc.target/riscv/pr93202.c -O2 -flto -flto-partition=none (test for
errors, line 9)
gcc/testsuite/ChangeLog:
* gcc.target/riscv/interrupt-misaligned.c: Remove
"-fno-fat-lto-objects" from skip condition.
* gcc.target/riscv/pr93202.c: Likewise.
(cherry picked from commit 0717d50fc4ff983b79093bdef43b04e4584cc3cd)
Signed-off-by: Christoph Müllner
---
gcc/testsuite/gcc.target/riscv/interrupt-misaligned.c | 2 +-
gcc/testsuite/gcc.target/riscv/pr93202.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.target/riscv/interrupt-misaligned.c
b/gcc/testsuite/gcc.target/riscv/interrupt-misaligned.c
index b5f8e6c2bbe..912f180e4d6 100644
--- a/gcc/testsuite/gcc.target/riscv/interrupt-misaligned.c
+++ b/gcc/testsuite/gcc.target/riscv/interrupt-misaligned.c
@@ -1,6 +1,6 @@
/* { dg-do compile } */
/* { dg-options "-O2 -march=rv64gc -mabi=lp64d -fno-schedule-insns
-fno-schedule-insns2" } */
-/* { dg-skip-if "" { *-*-* } { "-flto -fno-fat-lto-objects" } } */
+/* { dg-skip-if "" { *-*-* } { "-flto" } } */
/* Make sure no stack offset are misaligned.
** interrupt:
diff --git a/gcc/testsuite/gcc.target/riscv/pr93202.c
b/gcc/testsuite/gcc.target/riscv/pr93202.c
index 5501191ea52..5de003fac42 100644
--- a/gcc/testsuite/gcc.target/riscv/pr93202.c
+++ b/gcc/testsuite/gcc.target/riscv/pr93202.c
@@ -1,7 +1,7 @@
/* PR inline-asm/93202 */
/* { dg-do compile { target fpic } } */
/* { dg-options "-fpic" } */
-/* { dg-skip-if "" { *-*-* } { "-flto -fno-fat-lto-objects" } } */
+/* { dg-skip-if "" { *-*-* } { "-flto" } } */
void
foo (void)
--
2.45.2
[committed][GCC-14] RISC-V: Fix comment/naming in attribute parsing code
Function target attributes have to be separated by semi-colons.
Let's fix the comment and variable naming to better explain what
the code does.
gcc/ChangeLog:
* config/riscv/riscv-target-attr.cc (riscv_process_target_attr):
Fix comments and variable names.
(cherry picked from commit 5ef0b7d2048a7142174ee3e8e021fc1a9c3e3334)
Signed-off-by: Christoph Müllner
---
gcc/config/riscv/riscv-target-attr.cc | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/config/riscv/riscv-target-attr.cc
b/gcc/config/riscv/riscv-target-attr.cc
index 19eb7b06d54..0bbe7df25d1 100644
--- a/gcc/config/riscv/riscv-target-attr.cc
+++ b/gcc/config/riscv/riscv-target-attr.cc
@@ -338,11 +338,11 @@ riscv_process_target_attr (tree fndecl, tree args,
location_t loc,
char *str_to_check = buf.get ();
strcpy (str_to_check, TREE_STRING_POINTER (args));
- /* Used to catch empty spaces between commas i.e.
+ /* Used to catch empty spaces between semi-colons i.e.
attribute ((target ("attr1;;attr2"))). */
- unsigned int num_commas = num_occurences_in_str (';', str_to_check);
+ unsigned int num_semicolons = num_occurences_in_str (';', str_to_check);
- /* Handle multiple target attributes separated by ','. */
+ /* Handle multiple target attributes separated by ';'. */
char *token = strtok_r (str_to_check, ";", &str_to_check);
riscv_target_attr_parser attr_parser (loc);
@@ -354,7 +354,7 @@ riscv_process_target_attr (tree fndecl, tree args,
location_t loc,
token = strtok_r (NULL, ";", &str_to_check);
}
- if (num_attrs != num_commas + 1)
+ if (num_attrs != num_semicolons + 1)
{
error_at (loc, "malformed % attribute",
TREE_STRING_POINTER (args));
--
2.45.2
[committed][GCC-14] RISC-V: Allow adding enabled extension via target arch attributes
The set of enabled extensions can be extended via target arch function
attributes by listing each extension with a '+' prefix and a comma as
list separator. E.g.:
__attribute__((target("arch=+zba,+zbb"))) void foo();
The programmer intends to ensure that one or more extensions
are enabled when building the code. This is independent of the arch
string that is passed at build time via the -march= option.
Therefore, it is reasonable to allow enabling extensions via target arch
attributes, which have already been enabled via the -march= string.
The subset list code already supports such duplication for implied
extensions. This patch adds an interface so the subset list
parser can be switched into a mode where duplication is allowed.
This commit fixes the following regressed test cases:
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-39.c
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-42.c
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-43.c
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-44.c
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-45.c
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-46.c
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_subset_list::add):
Allow adding enabled extension if m_allow_adding_dup is set.
* config/riscv/riscv-subset.h: Add m_allow_adding_dup and setter.
* config/riscv/riscv-target-attr.cc
(riscv_target_attr_parser::parse_arch):
Allow adding enabled extensions.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr115554.c: Change expected fail to expected pass.
* gcc.target/riscv/target-attr-16.c: New test.
(cherry picked from commit 61c21a719e205f70bd046c6a0275d1a3fd6341a4)
Signed-off-by: Christoph Müllner
---
gcc/common/config/riscv/riscv-common.cc | 17 +++
gcc/config/riscv/riscv-subset.h | 5
gcc/config/riscv/riscv-target-attr.cc | 3 ++
gcc/testsuite/gcc.target/riscv/pr115554.c | 2 --
.../gcc.target/riscv/target-attr-16.c | 28 +++
5 files changed, 47 insertions(+), 8 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/riscv/target-attr-16.c
diff --git a/gcc/common/config/riscv/riscv-common.cc
b/gcc/common/config/riscv/riscv-common.cc
index 2257b959acb..5212f67faad 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -663,12 +663,17 @@ riscv_subset_list::add (const char *subset, int
major_version,
ext->minor_version = minor_version;
}
else
- error_at (
- m_loc,
- "%<-march=%s%>: extension %qs appear more than one time",
- m_arch,
- subset);
-
+ {
+ /* The extension is already in the list. */
+ if (!m_allow_adding_dup
+ || ext->major_version != major_version
+ || ext->minor_version != minor_version)
+ error_at (
+ m_loc,
+ "%<-march=%s%>: extension %qs appear more than one time",
+ m_arch,
+ subset);
+ }
return;
}
else if (strlen (subset) == 1 && !standard_extensions_p (subset))
diff --git a/gcc/config/riscv/riscv-subset.h b/gcc/config/riscv/riscv-subset.h
index 256d2865746..c2d213c1734 100644
--- a/gcc/config/riscv/riscv-subset.h
+++ b/gcc/config/riscv/riscv-subset.h
@@ -62,6 +62,9 @@ private:
/* X-len of m_arch. */
unsigned m_xlen;
+ /* Allow adding the same extension more than once. */
+ bool m_allow_adding_dup;
+
riscv_subset_list (const char *, location_t);
const char *parsing_subset_version (const char *, const char *, unsigned *,
@@ -106,6 +109,8 @@ public:
void set_loc (location_t);
+ void set_allow_adding_dup (bool v) { m_allow_adding_dup = v; }
+
void finalize ();
};
diff --git a/gcc/config/riscv/riscv-target-attr.cc
b/gcc/config/riscv/riscv-target-attr.cc
index b514e68bf40..1645a669217 100644
--- a/gcc/config/riscv/riscv-target-attr.cc
+++ b/gcc/config/riscv/riscv-target-attr.cc
@@ -110,6 +110,8 @@ riscv_target_attr_parser::parse_arch (const char *str)
? riscv_subset_list::parse (local_arch_str, m_loc)
: riscv_cmdline_subset_list ()->clone ();
m_subset_list->set_loc (m_loc);
+ m_subset_list->set_allow_adding_dup (true);
+
while (token)
{
if (token[0] != '+')
@@ -135,6 +137,7 @@ riscv_target_attr_parser::parse_arch (const char *str)
token = strtok_r (NULL, ",", &str_to_check);
}
+ m_subset_list->set_allow_adding_dup (false);
m_subset_list->finalize ();
return true;
}
diff --git a/gcc/testsuite/gcc.target/riscv/pr115554.c
b/gcc/testsuite/gcc.target/riscv/pr115554.c
index e7dcde6276f..16d5f63aac0 100644
--- a/gcc/testsuite/gcc.t
[committed][GCC-14] RISC-V: Deduplicate arch subset list processing
We have a code duplication in riscv_set_arch_by_subset_list() and
riscv_parse_arch_string(), where the latter function parses an ISA string
into a subset_list before doing the same as the former function.
riscv_parse_arch_string() is used to process command line options and
riscv_set_arch_by_subset_list() processes target attributes.
So, it is obvious that both functions should do the same.
Let's deduplicate the code to enforce this.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_set_arch_by_subset_list):
Fix overlong line.
(riscv_parse_arch_string): Replace duplicated code by a call to
riscv_set_arch_by_subset_list.
(cherry picked from commit 85fa334fbcaa8e4b98ab197a8c9410dde87f0ae3)
Signed-off-by: Christoph Müllner
---
gcc/common/config/riscv/riscv-common.cc | 32 +
1 file changed, 6 insertions(+), 26 deletions(-)
diff --git a/gcc/common/config/riscv/riscv-common.cc
b/gcc/common/config/riscv/riscv-common.cc
index 43b7549e3ec..cc43c8dd6b4 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -1779,7 +1779,8 @@ riscv_set_arch_by_subset_list (riscv_subset_list
*subset_list,
else if (subset_list->xlen () == 64)
opts->x_target_flags |= MASK_64BIT;
- for (arch_ext_flag_tab = &riscv_ext_flag_table[0];
arch_ext_flag_tab->ext;
+ for (arch_ext_flag_tab = &riscv_ext_flag_table[0];
+ arch_ext_flag_tab->ext;
++arch_ext_flag_tab)
{
if (subset_list->lookup (arch_ext_flag_tab->ext))
@@ -1803,30 +1804,6 @@ riscv_parse_arch_string (const char *isa,
if (!subset_list)
return;
- if (opts)
-{
- const riscv_ext_flag_table_t *arch_ext_flag_tab;
- /* Clean up target flags before we set. */
- for (arch_ext_flag_tab = &riscv_ext_flag_table[0];
- arch_ext_flag_tab->ext;
- ++arch_ext_flag_tab)
- opts->*arch_ext_flag_tab->var_ref &= ~arch_ext_flag_tab->mask;
-
- if (subset_list->xlen () == 32)
- opts->x_target_flags &= ~MASK_64BIT;
- else if (subset_list->xlen () == 64)
- opts->x_target_flags |= MASK_64BIT;
-
-
- for (arch_ext_flag_tab = &riscv_ext_flag_table[0];
- arch_ext_flag_tab->ext;
- ++arch_ext_flag_tab)
- {
- if (subset_list->lookup (arch_ext_flag_tab->ext))
- opts->*arch_ext_flag_tab->var_ref |= arch_ext_flag_tab->mask;
- }
-}
-
/* Avoid double delete if current_subset_list equals cmdline_subset_list. */
if (current_subset_list && current_subset_list != cmdline_subset_list)
delete current_subset_list;
@@ -1834,7 +1811,10 @@ riscv_parse_arch_string (const char *isa,
if (cmdline_subset_list)
delete cmdline_subset_list;
- current_subset_list = cmdline_subset_list = subset_list;
+ cmdline_subset_list = subset_list;
+ /* current_subset_list is set in the call below. */
+
+ riscv_set_arch_by_subset_list (subset_list, opts);
}
/* Return the riscv_cpu_info entry for CPU, NULL if not found. */
--
2.45.2
[committed][GCC-14] RISC-V: Rewrite target attribute handling
* gcc.target/riscv/target-attr-07.c: Likewise.
* gcc.target/riscv/pr115554.c: New test.
* gcc.target/riscv/pr115562.c: New test.
* gcc.target/riscv/target-attr-08.c: New test.
* gcc.target/riscv/target-attr-09.c: New test.
* gcc.target/riscv/target-attr-10.c: New test.
* gcc.target/riscv/target-attr-11.c: New test.
* gcc.target/riscv/target-attr-12.c: New test.
* gcc.target/riscv/target-attr-13.c: New test.
* gcc.target/riscv/target-attr-14.c: New test.
* gcc.target/riscv/target-attr-15.c: New test.
(cherry picked from commit aa8e2de78cae4dca7f9b0efe0685f3382f9ecb9a)
Signed-off-by: Christoph Müllner
---
gcc/common/config/riscv/riscv-common.cc | 113 +-
gcc/config/riscv/riscv-c.cc | 2 +-
gcc/config/riscv/riscv-subset.h | 4 -
gcc/config/riscv/riscv-target-attr.cc | 102 +---
gcc/config/riscv/riscv.cc | 22 ++--
gcc/config/riscv/riscv.opt| 2 +-
gcc/testsuite/gcc.target/riscv/pr115554.c | 13 ++
gcc/testsuite/gcc.target/riscv/pr115562.c | 25
.../gcc.target/riscv/target-attr-01.c | 16 ++-
.../gcc.target/riscv/target-attr-02.c | 16 ++-
.../gcc.target/riscv/target-attr-03.c | 11 +-
.../gcc.target/riscv/target-attr-04.c | 11 +-
.../gcc.target/riscv/target-attr-05.c | 10 +-
.../gcc.target/riscv/target-attr-06.c | 11 +-
.../gcc.target/riscv/target-attr-07.c | 10 +-
.../gcc.target/riscv/target-attr-08.c | 20
.../gcc.target/riscv/target-attr-09.c | 19 +++
.../gcc.target/riscv/target-attr-10.c | 19 +++
.../gcc.target/riscv/target-attr-11.c | 22
.../gcc.target/riscv/target-attr-12.c | 21
.../gcc.target/riscv/target-attr-13.c | 21
.../gcc.target/riscv/target-attr-14.c | 42 +++
.../gcc.target/riscv/target-attr-15.c | 42 +++
23 files changed, 371 insertions(+), 203 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/riscv/pr115554.c
create mode 100644 gcc/testsuite/gcc.target/riscv/pr115562.c
create mode 100644 gcc/testsuite/gcc.target/riscv/target-attr-08.c
create mode 100644 gcc/testsuite/gcc.target/riscv/target-attr-09.c
create mode 100644 gcc/testsuite/gcc.target/riscv/target-attr-10.c
create mode 100644 gcc/testsuite/gcc.target/riscv/target-attr-11.c
create mode 100644 gcc/testsuite/gcc.target/riscv/target-attr-12.c
create mode 100644 gcc/testsuite/gcc.target/riscv/target-attr-13.c
create mode 100644 gcc/testsuite/gcc.target/riscv/target-attr-14.c
create mode 100644 gcc/testsuite/gcc.target/riscv/target-attr-15.c
diff --git a/gcc/common/config/riscv/riscv-common.cc
b/gcc/common/config/riscv/riscv-common.cc
index cc43c8dd6b4..2257b959acb 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -424,110 +424,13 @@ static const char *riscv_supported_std_ext (void);
bool riscv_subset_list::parse_failed = false;
-static riscv_subset_list *current_subset_list = NULL;
-
static riscv_subset_list *cmdline_subset_list = NULL;
-struct riscv_func_target_info
-{
- tree fn_decl;
- std::string fn_target_name;
-
- riscv_func_target_info (const tree &decl, const std::string &target_name)
-: fn_decl (decl), fn_target_name (target_name)
- {
- }
-};
-
-struct riscv_func_target_hasher : nofree_ptr_hash
-{
- typedef tree compare_type;
-
- static hashval_t hash (value_type);
- static bool equal (value_type, const compare_type &);
-};
-
-static hash_table *func_target_table = NULL;
-
-static inline hashval_t riscv_func_decl_hash (tree fn_decl)
-{
- inchash::hash h;
-
- h.add_ptr (fn_decl);
-
- return h.end ();
-}
-
-inline hashval_t
-riscv_func_target_hasher::hash (value_type value)
-{
- return riscv_func_decl_hash (value->fn_decl);
-}
-
-inline bool
-riscv_func_target_hasher::equal (value_type value, const compare_type &key)
-{
- return value->fn_decl == key;
-}
-
-const riscv_subset_list *riscv_current_subset_list ()
-{
- return current_subset_list;
-}
-
-const riscv_subset_list * riscv_cmdline_subset_list ()
+const riscv_subset_list *riscv_cmdline_subset_list ()
{
return cmdline_subset_list;
}
-static inline void riscv_func_target_table_lazy_init ()
-{
- if (func_target_table != NULL)
-return;
-
- func_target_table = new hash_table (1023);
-}
-
-std::string * riscv_func_target_get (tree fn_decl)
-{
- riscv_func_target_table_lazy_init ();
-
- hashval_t hash = riscv_func_decl_hash (fn_decl);
- struct riscv_func_target_info *info
-= func_target_table->find_with_hash (fn_decl, hash);
-
- return info == NULL ? NULL : &info->fn_target_name;
-}
-
-void riscv_func_target_put (tree fn_decl, std::string fn_target_name)
-{
- riscv_func_target_table_lazy_init ();
-
- hashval_t hash = riscv_func_decl_hash
Re: [PATCH] RISC-V: Fix testcase missing arch attribute
On Wed, Jul 17, 2024 at 3:15 AM Edwin Lu wrote:
>
> The C + F extentions implies the zcf extension on rv32. Add missing zcf
> extension for the rv32 target.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/target-attr-16.c: Update expected assembly
>
> Signed-off-by: Edwin Lu
> ---
> gcc/testsuite/gcc.target/riscv/target-attr-16.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Christoph Müllner
In my defense, I tested the following combinations:
= Summary of gcc testsuite =
| # of unexpected case / # of unique unexpected case
| gcc | g++ | gfortran |
rv32imac/ ilp32/ medlow | 33 / 8 |0 / 0 |0 / 0 |
rv32imafdc/ ilp32d/ medlow | 33 / 8 |0 / 0 |0 / 0 |
rv64imac/ lp64/ medlow | 25 / 8 |0 / 0 |0 / 0 |
rv64imafdc/ lp64d/ medlow | 25 / 8 |0 / 0 |0 / 0 |
But it seems I missed looking into the details of the failing rv32 tests, where
reg_subreg_costs.c does not fail, but target-attr-16.c does.
FWIW, GCC-14 is not affected.
> diff --git a/gcc/testsuite/gcc.target/riscv/target-attr-16.c
> b/gcc/testsuite/gcc.target/riscv/target-attr-16.c
> index 1c7badccdee..c6b626d0c6c 100644
> --- a/gcc/testsuite/gcc.target/riscv/target-attr-16.c
> +++ b/gcc/testsuite/gcc.target/riscv/target-attr-16.c
> @@ -24,5 +24,5 @@ void bar (void)
> {
> }
>
> -/* { dg-final { scan-assembler-times ".option arch,
> rv32i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0_zaamo1p0_zalrsc1p0_zca1p0_zcd1p0_zba1p0_zbb1p0"
> 4 { target { rv32 } } } } */
> +/* { dg-final { scan-assembler-times ".option arch,
> rv32i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0_zaamo1p0_zalrsc1p0_zca1p0_zcd1p0_zcf1p0_zba1p0_zbb1p0"
> 4 { target { rv32 } } } } */
> /* { dg-final { scan-assembler-times ".option arch,
> rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0_zaamo1p0_zalrsc1p0_zca1p0_zcd1p0_zba1p0_zbb1p0"
> 4 { target { rv64 } } } } */
> --
> 2.34.1
>
Re: [PATCH 1/2] RISC-V: Add tests for cpymemsi expansion
On Fri, May 10, 2024 at 6:01 AM Patrick O'Neill wrote:
>
> Hi Christoph,
>
> cpymemsi-1.c fails on a subset of newlib targets.
>
> "UNRESOLVED: gcc.target/riscv/cpymemsi-1.c -O0 compilation failed to
> produce executable"
>
> Full list of failing targets here (New Failures section):
> https://github.com/patrick-rivos/gcc-postcommit-ci/issues/906
Thanks for reporting!
I'm having a hard time figuring out what the issue is here, as I can't
reproduce it locally.
This test is an execution test ("dg-do run"), so I wonder if this
might be the issue?
Thanks,
Christoph
>
> Thanks,
>
> Patrick
>
> On 5/7/24 22:52, Christoph Müllner wrote:
> > cpymemsi expansion was available for RISC-V since the initial port.
> > However, there are not tests to detect regression.
> > This patch adds such tests.
> >
> > Three of the tests target the expansion requirements (known length and
> > alignment). One test reuses an existing memcpy test from the by-pieces
> > framework (gcc/testsuite/gcc.dg/torture/inline-mem-cpy-1.c).
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/riscv/cpymemsi-1.c: New test.
> > * gcc.target/riscv/cpymemsi-2.c: New test.
> > * gcc.target/riscv/cpymemsi-3.c: New test.
> > * gcc.target/riscv/cpymemsi.c: New test.
> >
> > Signed-off-by: Christoph Müllner
> > ---
[PATCH] RISC-V: Fix cbo.zero expansion for rv32
Emitting a DI pattern won't find a match for rv32 and manifests in
the failing test case gcc.target/riscv/cmo-zicboz-zic64-1.c.
Let's fix this in the expansion and also address the different
code that gets generated for rv32/rv64.
gcc/ChangeLog:
* config/riscv/riscv-string.cc (riscv_expand_block_clear_zicboz_zic64b):
Fix expansion for rv32.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/cmo-zicboz-zic64-1.c: Fix for rv32.
Signed-off-by: Christoph Müllner
---
gcc/config/riscv/riscv-string.cc | 5 ++-
.../gcc.target/riscv/cmo-zicboz-zic64-1.c | 36 ++-
2 files changed, 14 insertions(+), 27 deletions(-)
diff --git a/gcc/config/riscv/riscv-string.cc b/gcc/config/riscv/riscv-string.cc
index 87f5fdee3c1..b515f44d17a 100644
--- a/gcc/config/riscv/riscv-string.cc
+++ b/gcc/config/riscv/riscv-string.cc
@@ -827,7 +827,10 @@ riscv_expand_block_clear_zicboz_zic64b (rtx dest, rtx
length)
{
rtx mem = adjust_address (dest, BLKmode, offset);
rtx addr = force_reg (Pmode, XEXP (mem, 0));
- emit_insn (gen_riscv_zero_di (addr));
+ if (TARGET_64BIT)
+ emit_insn (gen_riscv_zero_di (addr));
+ else
+ emit_insn (gen_riscv_zero_si (addr));
offset += cbo_bytes;
}
diff --git a/gcc/testsuite/gcc.target/riscv/cmo-zicboz-zic64-1.c
b/gcc/testsuite/gcc.target/riscv/cmo-zicboz-zic64-1.c
index c2d79eb7ae6..9192b391b11 100644
--- a/gcc/testsuite/gcc.target/riscv/cmo-zicboz-zic64-1.c
+++ b/gcc/testsuite/gcc.target/riscv/cmo-zicboz-zic64-1.c
@@ -1,25 +1,9 @@
/* { dg-do compile } */
-/* { dg-options "-march=rv64gc_zic64b_zicboz" { target { rv64 } } } */
/* { dg-options "-march=rv32gc_zic64b_zicboz" { target { rv32 } } } */
+/* { dg-options "-march=rv64gc_zic64b_zicboz" { target { rv64 } } } */
/* { dg-skip-if "" { *-*-* } {"-O0" "-Os" "-Og" "-Oz" "-flto" } } */
-/* { dg-final { check-function-bodies "**" "" } } */
-/* { dg-allow-blank-lines-in-output 1 } */
-/*
-**clear_buf_123:
-**...
-**cbo\.zero\t0\(a[0-9]+\)
-**sd\tzero,64\(a[0-9]+\)
-**sd\tzero,72\(a[0-9]+\)
-**sd\tzero,80\(a[0-9]+\)
-**sd\tzero,88\(a[0-9]+\)
-**sd\tzero,96\(a[0-9]+\)
-**sd\tzero,104\(a[0-9]+\)
-**sd\tzero,112\(a[0-9]+\)
-**sh\tzero,120\(a[0-9]+\)
-**sb\tzero,122\(a[0-9]+\)
-**...
-*/
+// 1x cbo.zero, 7x sd (rv64) or 14x sw (rv32), 1x sh, 1x sb
int
clear_buf_123 (void *p)
{
@@ -27,17 +11,17 @@ clear_buf_123 (void *p)
__builtin_memset (p, 0, 123);
}
-/*
-**clear_buf_128:
-**...
-**cbo\.zero\t0\(a[0-9]+\)
-**addi\ta[0-9]+,a[0-9]+,64
-**cbo\.zero\t0\(a[0-9]+\)
-**...
-*/
+// 2x cbo.zero, 1x addi 64
int
clear_buf_128 (void *p)
{
p = __builtin_assume_aligned(p, 64);
__builtin_memset (p, 0, 128);
}
+
+/* { dg-final { scan-assembler-times "cbo\.zero\t" 3 } } */
+/* { dg-final { scan-assembler-times "addi\ta\[0-9\]+,a\[0-9\]+,64" 1 } } */
+/* { dg-final { scan-assembler-times "sd\t" 7 { target { rv64 } } } } */
+/* { dg-final { scan-assembler-times "sw\t" 14 { target { rv32 } } } } */
+/* { dg-final { scan-assembler-times "sh\t" 1 } } */
+/* { dg-final { scan-assembler-times "sb\t" 1 } } */
--
2.44.0
[PATCH v2 2/2] RISC-V: strcmp expansion: Use adjust_address() for address calculation
We have an arch-independent routine to generate an address with an offset.
Let's use that instead of doing the calculation in the backend.
gcc/ChangeLog:
* config/riscv/riscv-string.cc (emit_strcmp_scalar_load_and_compare):
Use adjust_address() to calculate MEM-PLUS pattern.
Signed-off-by: Christoph Müllner
---
gcc/config/riscv/riscv-string.cc | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/gcc/config/riscv/riscv-string.cc b/gcc/config/riscv/riscv-string.cc
index a4c7f27d904..488e781aea3 100644
--- a/gcc/config/riscv/riscv-string.cc
+++ b/gcc/config/riscv/riscv-string.cc
@@ -227,8 +227,6 @@ emit_strcmp_scalar_load_and_compare (rtx result, rtx src1,
rtx src2,
rtx final_label)
{
const unsigned HOST_WIDE_INT xlen = GET_MODE_SIZE (Xmode);
- rtx src1_addr = force_reg (Pmode, XEXP (src1, 0));
- rtx src2_addr = force_reg (Pmode, XEXP (src2, 0));
unsigned HOST_WIDE_INT offset = 0;
rtx testval = gen_reg_rtx (Xmode);
@@ -246,10 +244,10 @@ emit_strcmp_scalar_load_and_compare (rtx result, rtx
src1, rtx src2,
else
load_mode = Xmode;
- rtx addr1 = gen_rtx_PLUS (Pmode, src1_addr, GEN_INT (offset));
- do_load_from_addr (load_mode, data1, addr1, src1);
- rtx addr2 = gen_rtx_PLUS (Pmode, src2_addr, GEN_INT (offset));
- do_load_from_addr (load_mode, data2, addr2, src2);
+ rtx addr1 = adjust_address (src1, load_mode, offset);
+ do_load (load_mode, data1, addr1);
+ rtx addr2 = adjust_address (src2, load_mode, offset);
+ do_load (load_mode, data2, addr2);
if (cmp_bytes == 1)
{
--
2.44.0
[PATCH v2 1/2] RISC-V: Add cmpmemsi expansion
GCC has a generic cmpmemsi expansion via the by-pieces framework, which shows some room for target-specific optimizations. E.g. for comparing two aligned memory blocks of 15 bytes we get the following sequence: my_mem_cmp_aligned_15: li a4,0 j .L2 .L8: bgeua4,a7,.L7 .L2: add a2,a0,a4 add a3,a1,a4 lbu a5,0(a2) lbu a6,0(a3) addia4,a4,1 li a7,15// missed hoisting subwa5,a5,a6 andia5,a5,0xff // useless beq a5,zero,.L8 lbu a0,0(a2) // loading again! lbu a5,0(a3) // loading again! subwa0,a0,a5 ret .L7: li a0,0 ret Diff first byte: 15 insns Diff second byte: 25 insns No diff: 25 insns Possible improvements: * unroll the loop and use load-with-displacement to avoid offset increments * load and compare multiple (aligned) bytes at once * Use the bitmanip/strcmp result calculation (reverse words and synthesize (a2 >= a3) ? 1 : -1 in a branchless sequence) When applying these improvements we get the following sequence: my_mem_cmp_aligned_15: ld a5,0(a0) ld a4,0(a1) bne a5,a4,.L2 ld a5,8(a0) ld a4,8(a1) sllia5,a5,8 sllia4,a4,8 bne a5,a4,.L2 li a0,0 .L3: sext.w a0,a0 ret .L2: rev8a5,a5 rev8a4,a4 sltua5,a5,a4 neg a5,a5 ori a0,a5,1 j .L3 Diff first byte: 11 insns Diff second byte: 16 insns No diff: 11 insns This patch implements this improvements. The tests consist of a execution test (similar to gcc/testsuite/gcc.dg/torture/inline-mem-cmp-1.c) and a few tests that test the expansion conditions (known length and alignment). Similar to the cpymemsi expansion this patch does not introduce any gating for the cmpmemsi expansion (on top of requiring the known length, alignment and Zbb). Bootstrapped and SPEC CPU 2017 tested. gcc/ChangeLog: * config/riscv/riscv-protos.h (riscv_expand_block_compare): New prototype. * config/riscv/riscv-string.cc (GEN_EMIT_HELPER2): New helper for zero_extendhi. (do_load_from_addr): Add support for HI and SI/64 modes. (do_load): Add helper for zero-extended loads. (emit_memcmp_scalar_load_and_compare): New helper to emit memcmp. (emit_memcmp_scalar_result_calculation): Likewise. (riscv_expand_block_compare_scalar): Likewise. (riscv_expand_block_compare): New RISC-V expander for memory compare. * config/riscv/riscv.md (cmpmemsi): New cmpmem expansion. gcc/testsuite/ChangeLog: * gcc.target/riscv/cmpmemsi-1.c: New test. * gcc.target/riscv/cmpmemsi-2.c: New test. * gcc.target/riscv/cmpmemsi-3.c: New test. * gcc.target/riscv/cmpmemsi.c: New test. Signed-off-by: Christoph Müllner --- gcc/config/riscv/riscv-protos.h | 1 + gcc/config/riscv/riscv-string.cc| 218 ++-- gcc/config/riscv/riscv.md | 15 ++ gcc/testsuite/gcc.target/riscv/cmpmemsi-1.c | 6 + gcc/testsuite/gcc.target/riscv/cmpmemsi-2.c | 42 gcc/testsuite/gcc.target/riscv/cmpmemsi-3.c | 43 gcc/testsuite/gcc.target/riscv/cmpmemsi.c | 22 ++ 7 files changed, 333 insertions(+), 14 deletions(-) create mode 100644 gcc/testsuite/gcc.target/riscv/cmpmemsi-1.c create mode 100644 gcc/testsuite/gcc.target/riscv/cmpmemsi-2.c create mode 100644 gcc/testsuite/gcc.target/riscv/cmpmemsi-3.c create mode 100644 gcc/testsuite/gcc.target/riscv/cmpmemsi.c diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h index 5c8a52b78a2..565ead1382a 100644 --- a/gcc/config/riscv/riscv-protos.h +++ b/gcc/config/riscv/riscv-protos.h @@ -189,6 +189,7 @@ rtl_opt_pass * make_pass_avlprop (gcc::context *ctxt); rtl_opt_pass * make_pass_vsetvl (gcc::context *ctxt); /* Routines implemented in riscv-string.c. */ +extern bool riscv_expand_block_compare (rtx, rtx, rtx, rtx); extern bool riscv_expand_block_move (rtx, rtx, rtx); extern bool riscv_expand_block_clear (rtx, rtx); diff --git a/gcc/config/riscv/riscv-string.cc b/gcc/config/riscv/riscv-string.cc index 87f5fdee3c1..a4c7f27d904 100644 --- a/gcc/config/riscv/riscv-string.cc +++ b/gcc/config/riscv/riscv-string.cc @@ -86,35 +86,47 @@ GEN_EMIT_HELPER2(th_rev) /* do_th_rev2 */ GEN_EMIT_HELPER2(th_tstnbz) /* do_th_tstnbz2 */ GEN_EMIT_HELPER3(xor) /* do_xor3 */ GEN_EMIT_HELPER2(zero_extendqi) /* do_zero_extendqi2 */ +GEN_EMIT_HELPER2(zero_extendhi) /* do_zero_extendhi2 */ #undef GEN_EMIT_HELPER2 #undef GEN_EMIT_HELPER3 -/* Helper function to load a byte or a Pmode register. +/* Helper function to emit zero-extended loads. - MODE is the mode to use for the load (QImode or Pmode). + MODE is the mode to use for the load. DEST is the destinat
Re: [PATCH 2/2] RISC-V: Add cmpmemsi expansion
On Thu, May 9, 2024 at 4:50 PM Jeff Law wrote: > > > > On 5/7/24 11:52 PM, Christoph Müllner wrote: > > GCC has a generic cmpmemsi expansion via the by-pieces framework, > > which shows some room for target-specific optimizations. > > E.g. for comparing two aligned memory blocks of 15 bytes > > we get the following sequence: > > > > my_mem_cmp_aligned_15: > > li a4,0 > > j .L2 > > .L8: > > bgeua4,a7,.L7 > > .L2: > > add a2,a0,a4 > > add a3,a1,a4 > > lbu a5,0(a2) > > lbu a6,0(a3) > > addia4,a4,1 > > li a7,15// missed hoisting > > subwa5,a5,a6 > > andia5,a5,0xff // useless > > beq a5,zero,.L8 > > lbu a0,0(a2) // loading again! > > lbu a5,0(a3) // loading again! > > subwa0,a0,a5 > > ret > > .L7: > > li a0,0 > > ret > > > > Diff first byte: 15 insns > > Diff second byte: 25 insns > > No diff: 25 insns > > > > Possible improvements: > > * unroll the loop and use load-with-displacement to avoid offset increments > > * load and compare multiple (aligned) bytes at once > > * Use the bitmanip/strcmp result calculation (reverse words and > >synthesize (a2 >= a3) ? 1 : -1 in a branchless sequence) > > > > When applying these improvements we get the following sequence: > > > > my_mem_cmp_aligned_15: > > ld a5,0(a0) > > ld a4,0(a1) > > bne a5,a4,.L2 > > ld a5,8(a0) > > ld a4,8(a1) > > sllia5,a5,8 > > sllia4,a4,8 > > bne a5,a4,.L2 > > li a0,0 > > .L3: > > sext.w a0,a0 > > ret > > .L2: > > rev8a5,a5 > > rev8a4,a4 > > sltua5,a5,a4 > > neg a5,a5 > > ori a0,a5,1 > > j .L3 > > > > Diff first byte: 11 insns > > Diff second byte: 16 insns > > No diff: 11 insns > > > > This patch implements this improvements. > > > > The tests consist of a execution test (similar to > > gcc/testsuite/gcc.dg/torture/inline-mem-cmp-1.c) and a few tests > > that test the expansion conditions (known length and alignment). > > > > Similar to the cpymemsi expansion this patch does not introduce any > > gating for the cmpmemsi expansion (on top of requiring the known length, > > alignment and Zbb). > > > > Bootstrapped and SPEC CPU 2017 tested. > > > > gcc/ChangeLog: > > > > * config/riscv/riscv-protos.h (riscv_expand_block_compare): New > > prototype. > > * config/riscv/riscv-string.cc (GEN_EMIT_HELPER2): New helper. > > (do_load_from_addr): Add support for HI and SI/64 modes. > > (emit_memcmp_scalar_load_and_compare): New helper to emit memcmp. > > (emit_memcmp_scalar_result_calculation): Likewise. > > (riscv_expand_block_compare_scalar): Likewise. > > (riscv_expand_block_compare): New RISC-V expander for memory compare. > > * config/riscv/riscv.md (cmpmemsi): New cmpmem expansion. > > > > gcc/testsuite/ChangeLog: > > > > * gcc.target/riscv/cmpmemsi-1.c: New test. > > * gcc.target/riscv/cmpmemsi-2.c: New test. > > * gcc.target/riscv/cmpmemsi-3.c: New test. > > * gcc.target/riscv/cmpmemsi.c: New test. > > > > Signed-off-by: Christoph Müllner > > --- > > gcc/config/riscv/riscv-protos.h | 1 + > > gcc/config/riscv/riscv-string.cc| 161 > > gcc/config/riscv/riscv.md | 15 ++ > > gcc/testsuite/gcc.target/riscv/cmpmemsi-1.c | 6 + > > gcc/testsuite/gcc.target/riscv/cmpmemsi-2.c | 42 + > > gcc/testsuite/gcc.target/riscv/cmpmemsi-3.c | 43 ++ > > gcc/testsuite/gcc.target/riscv/cmpmemsi.c | 22 +++ > > 7 files changed, 290 insertions(+) > > create mode 100644 gcc/testsuite/gcc.target/riscv/cmpmemsi-1.c > > create mode 100644 gcc/testsuite/gcc.target/riscv/cmpmemsi-2.c > > create mode 100644 gcc/testsuite/gcc.target/riscv/cmpmemsi-3.c > > create mode 100644 gcc/testsuite/gcc.target/riscv/cmpmemsi.c > > > > diff --git a/gcc/config/riscv/riscv-protos.h > > b/gcc/config/riscv/riscv-protos.h > > index e5aebf3fc3d..30ffe30be1d 100644
Re: [PATCH] RISC-V: Fix cbo.zero expansion for rv32
On Wed, May 15, 2024 at 9:14 AM Kito Cheng wrote:
>
> LGTM :)
Jeff already committed a fix before, which also disables the test for rv32.
I'll send up a follow-up patch to enable the test for rv32.
>
> On Wed, May 15, 2024 at 2:48 PM Christoph Müllner
> wrote:
> >
> > Emitting a DI pattern won't find a match for rv32 and manifests in
> > the failing test case gcc.target/riscv/cmo-zicboz-zic64-1.c.
> > Let's fix this in the expansion and also address the different
> > code that gets generated for rv32/rv64.
> >
> > gcc/ChangeLog:
> >
> > * config/riscv/riscv-string.cc
> > (riscv_expand_block_clear_zicboz_zic64b):
> > Fix expansion for rv32.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/riscv/cmo-zicboz-zic64-1.c: Fix for rv32.
> >
> > Signed-off-by: Christoph Müllner
> > ---
> > gcc/config/riscv/riscv-string.cc | 5 ++-
> > .../gcc.target/riscv/cmo-zicboz-zic64-1.c | 36 ++-
> > 2 files changed, 14 insertions(+), 27 deletions(-)
> >
> > diff --git a/gcc/config/riscv/riscv-string.cc
> > b/gcc/config/riscv/riscv-string.cc
> > index 87f5fdee3c1..b515f44d17a 100644
> > --- a/gcc/config/riscv/riscv-string.cc
> > +++ b/gcc/config/riscv/riscv-string.cc
> > @@ -827,7 +827,10 @@ riscv_expand_block_clear_zicboz_zic64b (rtx dest, rtx
> > length)
> > {
> >rtx mem = adjust_address (dest, BLKmode, offset);
> >rtx addr = force_reg (Pmode, XEXP (mem, 0));
> > - emit_insn (gen_riscv_zero_di (addr));
> > + if (TARGET_64BIT)
> > + emit_insn (gen_riscv_zero_di (addr));
> > + else
> > + emit_insn (gen_riscv_zero_si (addr));
> >offset += cbo_bytes;
> > }
> >
> > diff --git a/gcc/testsuite/gcc.target/riscv/cmo-zicboz-zic64-1.c
> > b/gcc/testsuite/gcc.target/riscv/cmo-zicboz-zic64-1.c
> > index c2d79eb7ae6..9192b391b11 100644
> > --- a/gcc/testsuite/gcc.target/riscv/cmo-zicboz-zic64-1.c
> > +++ b/gcc/testsuite/gcc.target/riscv/cmo-zicboz-zic64-1.c
> > @@ -1,25 +1,9 @@
> > /* { dg-do compile } */
> > -/* { dg-options "-march=rv64gc_zic64b_zicboz" { target { rv64 } } } */
> > /* { dg-options "-march=rv32gc_zic64b_zicboz" { target { rv32 } } } */
> > +/* { dg-options "-march=rv64gc_zic64b_zicboz" { target { rv64 } } } */
> > /* { dg-skip-if "" { *-*-* } {"-O0" "-Os" "-Og" "-Oz" "-flto" } } */
> > -/* { dg-final { check-function-bodies "**" "" } } */
> > -/* { dg-allow-blank-lines-in-output 1 } */
> >
> > -/*
> > -**clear_buf_123:
> > -**...
> > -**cbo\.zero\t0\(a[0-9]+\)
> > -**sd\tzero,64\(a[0-9]+\)
> > -**sd\tzero,72\(a[0-9]+\)
> > -**sd\tzero,80\(a[0-9]+\)
> > -**sd\tzero,88\(a[0-9]+\)
> > -**sd\tzero,96\(a[0-9]+\)
> > -**sd\tzero,104\(a[0-9]+\)
> > -**sd\tzero,112\(a[0-9]+\)
> > -**sh\tzero,120\(a[0-9]+\)
> > -**sb\tzero,122\(a[0-9]+\)
> > -**...
> > -*/
> > +// 1x cbo.zero, 7x sd (rv64) or 14x sw (rv32), 1x sh, 1x sb
> > int
> > clear_buf_123 (void *p)
> > {
> > @@ -27,17 +11,17 @@ clear_buf_123 (void *p)
> >__builtin_memset (p, 0, 123);
> > }
> >
> > -/*
> > -**clear_buf_128:
> > -**...
> > -**cbo\.zero\t0\(a[0-9]+\)
> > -**addi\ta[0-9]+,a[0-9]+,64
> > -**cbo\.zero\t0\(a[0-9]+\)
> > -**...
> > -*/
> > +// 2x cbo.zero, 1x addi 64
> > int
> > clear_buf_128 (void *p)
> > {
> >p = __builtin_assume_aligned(p, 64);
> >__builtin_memset (p, 0, 128);
> > }
> > +
> > +/* { dg-final { scan-assembler-times "cbo\.zero\t" 3 } } */
> > +/* { dg-final { scan-assembler-times "addi\ta\[0-9\]+,a\[0-9\]+,64" 1 } }
> > */
> > +/* { dg-final { scan-assembler-times "sd\t" 7 { target { rv64 } } } } */
> > +/* { dg-final { scan-assembler-times "sw\t" 14 { target { rv32 } } } } */
> > +/* { dg-final { scan-assembler-times "sh\t" 1 } } */
> > +/* { dg-final { scan-assembler-times "sb\t" 1 } } */
> > --
> > 2.44.0
> >
[PATCH] RISC-V: Test cbo.zero expansion for rv32
We had an issue when expanding via cmo-zero for RV32.
This was fixed upstream, but we don't have a RV32 test.
Therefore, this patch introduces such a test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/cmo-zicboz-zic64-1.c: Fix for rv32.
Signed-off-by: Christoph Müllner
---
.../gcc.target/riscv/cmo-zicboz-zic64-1.c | 37 ++-
1 file changed, 11 insertions(+), 26 deletions(-)
diff --git a/gcc/testsuite/gcc.target/riscv/cmo-zicboz-zic64-1.c
b/gcc/testsuite/gcc.target/riscv/cmo-zicboz-zic64-1.c
index 6d4535287d0..9192b391b11 100644
--- a/gcc/testsuite/gcc.target/riscv/cmo-zicboz-zic64-1.c
+++ b/gcc/testsuite/gcc.target/riscv/cmo-zicboz-zic64-1.c
@@ -1,24 +1,9 @@
/* { dg-do compile } */
-/* { dg-options "-march=rv64gc_zic64b_zicboz -mabi=lp64d" } */
+/* { dg-options "-march=rv32gc_zic64b_zicboz" { target { rv32 } } } */
+/* { dg-options "-march=rv64gc_zic64b_zicboz" { target { rv64 } } } */
/* { dg-skip-if "" { *-*-* } {"-O0" "-Os" "-Og" "-Oz" "-flto" } } */
-/* { dg-final { check-function-bodies "**" "" } } */
-/* { dg-allow-blank-lines-in-output 1 } */
-/*
-**clear_buf_123:
-**...
-**cbo\.zero\t0\(a[0-9]+\)
-**sd\tzero,64\(a[0-9]+\)
-**sd\tzero,72\(a[0-9]+\)
-**sd\tzero,80\(a[0-9]+\)
-**sd\tzero,88\(a[0-9]+\)
-**sd\tzero,96\(a[0-9]+\)
-**sd\tzero,104\(a[0-9]+\)
-**sd\tzero,112\(a[0-9]+\)
-**sh\tzero,120\(a[0-9]+\)
-**sb\tzero,122\(a[0-9]+\)
-**...
-*/
+// 1x cbo.zero, 7x sd (rv64) or 14x sw (rv32), 1x sh, 1x sb
int
clear_buf_123 (void *p)
{
@@ -26,17 +11,17 @@ clear_buf_123 (void *p)
__builtin_memset (p, 0, 123);
}
-/*
-**clear_buf_128:
-**...
-**cbo\.zero\t0\(a[0-9]+\)
-**addi\ta[0-9]+,a[0-9]+,64
-**cbo\.zero\t0\(a[0-9]+\)
-**...
-*/
+// 2x cbo.zero, 1x addi 64
int
clear_buf_128 (void *p)
{
p = __builtin_assume_aligned(p, 64);
__builtin_memset (p, 0, 128);
}
+
+/* { dg-final { scan-assembler-times "cbo\.zero\t" 3 } } */
+/* { dg-final { scan-assembler-times "addi\ta\[0-9\]+,a\[0-9\]+,64" 1 } } */
+/* { dg-final { scan-assembler-times "sd\t" 7 { target { rv64 } } } } */
+/* { dg-final { scan-assembler-times "sw\t" 14 { target { rv32 } } } } */
+/* { dg-final { scan-assembler-times "sh\t" 1 } } */
+/* { dg-final { scan-assembler-times "sb\t" 1 } } */
--
2.44.0
