RE: [PATCH] RISC-V: Remove incorrect earliest vsetvl post optimization[PR111313]

2023-09-06 Thread Li, Pan2 via Gcc-patches
Committed, thanks Kito.

Pan

-Original Message-
From: Gcc-patches  On Behalf 
Of Kito Cheng via Gcc-patches
Sent: Thursday, September 7, 2023 11:39 AM
To: Juzhe-Zhong 
Cc: GCC Patches ; Kito Cheng 
Subject: Re: [PATCH] RISC-V: Remove incorrect earliest vsetvl post 
optimization[PR111313]

LGTM

Juzhe-Zhong  於 2023年9月7日 週四 11:36 寫道:

> This patch removes the incorrect earliest poset vsetvl optimization,
> such bug was found in vect-double-reduc-5.c which is runtime(execution
> fail) and also in PR111313.
>
> For VLMAX intrinsics, we always emit a bogus patter which is vlmax_avl
> (see vector.md) to
> occupy a scalar register which is used by the following RVV instruction
> which is VLMAX AVL.
>
> Then for O2, O3, Ofast, earliest LCM works so well.
> However, for O1, the vlmax_avl is not well optimized in the before pass
> which confused LCM earliest
> so that we will end up with some redundant vsetvli zero,zero instructions
> in O1. (Note that O2 O3 Ofast are all good).
>
> To elide those redundant vsetvli zero,zero, I added
> cleanup_earliest_vsetvls to elide those redundant vsetvls.
>
> Now, after I review the implementation of this post optimizaiton again, I
> found it is incorrect and it is hard to
> do the post optimizations for vsetvls that earliest LCM failed to
> eliminate.
>
> Besides, such performance issues only happen in O1 or O0, such issues may
> not be serious.
> So remove it and we may will find another way (E.g. adjust vlmax_avl
> pattern COST)
> to optimize it if we really need to care about performance for O1.
>
> PR target/111313
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-vsetvl.cc
> (pass_vsetvl::cleanup_earliest_vsetvls): Remove.
> (pass_vsetvl::df_post_optimization): Remove incorrect function.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/vsetvl/avl_single-13.c: Adapt test.
> * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-17.c: Skip check for
> O1.
> * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-18.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-19.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-20.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-1.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-10.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-11.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-12.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-13.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-14.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-15.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-16.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-17.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-18.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-19.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-2.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-20.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-21.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-22.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-23.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-24.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-25.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-26.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-27.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-28.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-3.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-4.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-5.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-6.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-7.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-8.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-9.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-2.c: Ditto.
> * gcc.target/riscv/rvv/autovec/pr111313.c: New test.
>
> ---
>  gcc/config/riscv/riscv-vsetvl.cc  | 58 ---
>  .../gcc.target/riscv/rvv/autovec/pr111313.c   | 20 +++
>  .../riscv/rvv/vsetvl/avl_single-13.c  |  2 +-
>  .../riscv/rvv/vsetvl/vlmax_bb_prop-17.c   |  8 +--
>  .../riscv/rvv/vsetvl/vlmax_bb_prop-18.c   |  8 +--
>  .../riscv/rvv/vsetvl/vlmax_bb_prop-19.c   |  2 +-
>  .../riscv/rvv/vsetvl/vlmax_bb_prop-20.c   |  4 +-
>  .../gcc.target/riscv/rvv/vsetvl/vlmax_phi-1.c |  2 +-
>  .../riscv/rvv/vsetvl/vlmax_phi-10.c   |  2 +-
>  .../riscv/rvv/vsetvl/vlmax_phi-11.c   |  2 +-
>  .../riscv/rvv/vsetvl/vlmax_phi-12.c   |  2 +-
>  .../riscv/rvv/vsetvl/vlmax_phi-13.c   |  2 +-
>  .../riscv/rvv/vsetvl/vlmax_phi-14.c   |  2 +-
>  .../riscv/rvv/vsetvl/vlmax_phi-15.c   |  2 +-
>  .../riscv/rvv/vsetvl/vlmax_phi-16.c   |  2 +-
>  .../riscv/rvv/vsetvl/vlmax_phi-17.c   |  2 +-
>  

Re: [PATCH] RISC-V: Remove incorrect earliest vsetvl post optimization[PR111313]

2023-09-06 Thread Kito Cheng via Gcc-patches
LGTM

Juzhe-Zhong  於 2023年9月7日 週四 11:36 寫道:

> This patch removes the incorrect earliest poset vsetvl optimization,
> such bug was found in vect-double-reduc-5.c which is runtime(execution
> fail) and also in PR111313.
>
> For VLMAX intrinsics, we always emit a bogus patter which is vlmax_avl
> (see vector.md) to
> occupy a scalar register which is used by the following RVV instruction
> which is VLMAX AVL.
>
> Then for O2, O3, Ofast, earliest LCM works so well.
> However, for O1, the vlmax_avl is not well optimized in the before pass
> which confused LCM earliest
> so that we will end up with some redundant vsetvli zero,zero instructions
> in O1. (Note that O2 O3 Ofast are all good).
>
> To elide those redundant vsetvli zero,zero, I added
> cleanup_earliest_vsetvls to elide those redundant vsetvls.
>
> Now, after I review the implementation of this post optimizaiton again, I
> found it is incorrect and it is hard to
> do the post optimizations for vsetvls that earliest LCM failed to
> eliminate.
>
> Besides, such performance issues only happen in O1 or O0, such issues may
> not be serious.
> So remove it and we may will find another way (E.g. adjust vlmax_avl
> pattern COST)
> to optimize it if we really need to care about performance for O1.
>
> PR target/111313
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-vsetvl.cc
> (pass_vsetvl::cleanup_earliest_vsetvls): Remove.
> (pass_vsetvl::df_post_optimization): Remove incorrect function.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/vsetvl/avl_single-13.c: Adapt test.
> * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-17.c: Skip check for
> O1.
> * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-18.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-19.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-20.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-1.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-10.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-11.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-12.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-13.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-14.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-15.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-16.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-17.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-18.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-19.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-2.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-20.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-21.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-22.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-23.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-24.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-25.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-26.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-27.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-28.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-3.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-4.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-5.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-6.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-7.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-8.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_phi-9.c: Ditto.
> * gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-2.c: Ditto.
> * gcc.target/riscv/rvv/autovec/pr111313.c: New test.
>
> ---
>  gcc/config/riscv/riscv-vsetvl.cc  | 58 ---
>  .../gcc.target/riscv/rvv/autovec/pr111313.c   | 20 +++
>  .../riscv/rvv/vsetvl/avl_single-13.c  |  2 +-
>  .../riscv/rvv/vsetvl/vlmax_bb_prop-17.c   |  8 +--
>  .../riscv/rvv/vsetvl/vlmax_bb_prop-18.c   |  8 +--
>  .../riscv/rvv/vsetvl/vlmax_bb_prop-19.c   |  2 +-
>  .../riscv/rvv/vsetvl/vlmax_bb_prop-20.c   |  4 +-
>  .../gcc.target/riscv/rvv/vsetvl/vlmax_phi-1.c |  2 +-
>  .../riscv/rvv/vsetvl/vlmax_phi-10.c   |  2 +-
>  .../riscv/rvv/vsetvl/vlmax_phi-11.c   |  2 +-
>  .../riscv/rvv/vsetvl/vlmax_phi-12.c   |  2 +-
>  .../riscv/rvv/vsetvl/vlmax_phi-13.c   |  2 +-
>  .../riscv/rvv/vsetvl/vlmax_phi-14.c   |  2 +-
>  .../riscv/rvv/vsetvl/vlmax_phi-15.c   |  2 +-
>  .../riscv/rvv/vsetvl/vlmax_phi-16.c   |  2 +-
>  .../riscv/rvv/vsetvl/vlmax_phi-17.c   |  2 +-
>  .../riscv/rvv/vsetvl/vlmax_phi-18.c   |  2 +-
>  .../riscv/rvv/vsetvl/vlmax_phi-19.c   |  2 +-
>  .../gcc.target/riscv/rvv/vsetvl/vlmax_phi-2.c |  2 +-
>  .../riscv/rvv/vsetvl/vlmax_phi-20.c   |  2 +-
>  .../riscv/rvv/vsetvl/vlmax_phi-21.c   |  2 +-
>  

[PATCH] RISC-V: Remove incorrect earliest vsetvl post optimization[PR111313]

2023-09-06 Thread Juzhe-Zhong
This patch removes the incorrect earliest poset vsetvl optimization,
such bug was found in vect-double-reduc-5.c which is runtime(execution fail) 
and also in PR111313.

For VLMAX intrinsics, we always emit a bogus patter which is vlmax_avl (see 
vector.md) to
occupy a scalar register which is used by the following RVV instruction which 
is VLMAX AVL.

Then for O2, O3, Ofast, earliest LCM works so well.
However, for O1, the vlmax_avl is not well optimized in the before pass which 
confused LCM earliest
so that we will end up with some redundant vsetvli zero,zero instructions in 
O1. (Note that O2 O3 Ofast are all good).

To elide those redundant vsetvli zero,zero, I added cleanup_earliest_vsetvls to 
elide those redundant vsetvls.

Now, after I review the implementation of this post optimizaiton again, I found 
it is incorrect and it is hard to
do the post optimizations for vsetvls that earliest LCM failed to eliminate.

Besides, such performance issues only happen in O1 or O0, such issues may not 
be serious.
So remove it and we may will find another way (E.g. adjust vlmax_avl pattern 
COST) 
to optimize it if we really need to care about performance for O1.

PR target/111313

gcc/ChangeLog:

* config/riscv/riscv-vsetvl.cc (pass_vsetvl::cleanup_earliest_vsetvls): 
Remove.
(pass_vsetvl::df_post_optimization): Remove incorrect function.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/vsetvl/avl_single-13.c: Adapt test.
* gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-17.c: Skip check for O1.
* gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-18.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-19.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-20.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-1.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-10.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-11.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-12.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-13.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-14.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-15.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-16.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-17.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-18.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-19.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-2.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-20.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-21.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-22.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-23.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-24.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-25.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-26.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-27.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-28.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-3.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-4.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-5.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-6.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-7.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-8.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-9.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/pr111313.c: New test.

---
 gcc/config/riscv/riscv-vsetvl.cc  | 58 ---
 .../gcc.target/riscv/rvv/autovec/pr111313.c   | 20 +++
 .../riscv/rvv/vsetvl/avl_single-13.c  |  2 +-
 .../riscv/rvv/vsetvl/vlmax_bb_prop-17.c   |  8 +--
 .../riscv/rvv/vsetvl/vlmax_bb_prop-18.c   |  8 +--
 .../riscv/rvv/vsetvl/vlmax_bb_prop-19.c   |  2 +-
 .../riscv/rvv/vsetvl/vlmax_bb_prop-20.c   |  4 +-
 .../gcc.target/riscv/rvv/vsetvl/vlmax_phi-1.c |  2 +-
 .../riscv/rvv/vsetvl/vlmax_phi-10.c   |  2 +-
 .../riscv/rvv/vsetvl/vlmax_phi-11.c   |  2 +-
 .../riscv/rvv/vsetvl/vlmax_phi-12.c   |  2 +-
 .../riscv/rvv/vsetvl/vlmax_phi-13.c   |  2 +-
 .../riscv/rvv/vsetvl/vlmax_phi-14.c   |  2 +-
 .../riscv/rvv/vsetvl/vlmax_phi-15.c   |  2 +-
 .../riscv/rvv/vsetvl/vlmax_phi-16.c   |  2 +-
 .../riscv/rvv/vsetvl/vlmax_phi-17.c   |  2 +-
 .../riscv/rvv/vsetvl/vlmax_phi-18.c   |  2 +-
 .../riscv/rvv/vsetvl/vlmax_phi-19.c   |  2 +-
 .../gcc.target/riscv/rvv/vsetvl/vlmax_phi-2.c |  2 +-
 .../riscv/rvv/vsetvl/vlmax_phi-20.c   |  2 +-
 .../riscv/rvv/vsetvl/vlmax_phi-21.c   |  2 +-
 .../riscv/rvv/vsetvl/vlmax_phi-22.c   |  2 +-
 .../riscv/rvv/vsetvl/vlmax_phi-23.c   |  2 +-
 .../riscv/rvv/vsetvl/vlmax_phi-24.c   |  2 +-
 .../riscv/rvv/vsetvl/vlmax_phi-25.c   |  2 +-
 

[PATCH] Checking undefined_p before using the vr

2023-09-06 Thread Jiufu Guo via Gcc-patches
Hi,

As discussed in PR111303:

For pattern "(X + C) / N": "div (plus@3 @0 INTEGER_CST@1) INTEGER_CST@2)",
Even if "X" has value-range and "X + C" does not overflow, "@3" may still
be undefined. Like below example:

_3 = _2 + -5;
if (0 != 0)
  goto ; [34.00%]
else
  goto ; [66.00%]
;;  succ:   3
;;  4

;; basic block 3, loop depth 0
;;  pred:   2
_5 = _3 / 5; 
;;  succ:   4

The whole pattern "(_2 + -5 ) / 5" is in "bb 3", but "bb 3" would be
unreachable (because "if (0 != 0)" is always false).
And "get_range_query (cfun)->range_of_expr (vr3, @3)" is checked in
"bb 3", "range_of_expr" gets an "undefined vr3". Where "@3" is "_5".

So, before using "vr3", it would be safe to check "!vr3.undefined_p ()".

Bootstrap & regtest pass on ppc64{,le} and x86_64.
Is this ok for trunk?

BR,
Jeff (Jiufu Guo)

PR middle-end/111303

gcc/ChangeLog:

* match.pd ((X - N * M) / N): Add undefined_p checking.
(X + N * M) / N): Likewise.
((X + C) div_rshift N): Likewise.

gcc/testsuite/ChangeLog:

* gcc.dg/pr111303.c: New test.

---
 gcc/match.pd|  3 +++
 gcc/testsuite/gcc.dg/pr111303.c | 11 +++
 2 files changed, 14 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/pr111303.c

diff --git a/gcc/match.pd b/gcc/match.pd
index 801edb128f9..e2583ca7960 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -975,6 +975,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
/* "X+(N*M)" doesn't overflow.  */
&& range_op_handler (PLUS_EXPR).overflow_free_p (vr0, vr3)
&& get_range_query (cfun)->range_of_expr (vr4, @4)
+   && !vr4.undefined_p ()
/* "X+N*M" is not with opposite sign as "X".  */
&& (TYPE_UNSIGNED (type)
   || (vr0.nonnegative_p () && vr4.nonnegative_p ())
@@ -995,6 +996,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
/* "X - (N*M)" doesn't overflow.  */
&& range_op_handler (MINUS_EXPR).overflow_free_p (vr0, vr3)
&& get_range_query (cfun)->range_of_expr (vr4, @4)
+   && !vr4.undefined_p ()
/* "X-N*M" is not with opposite sign as "X".  */
&& (TYPE_UNSIGNED (type)
   || (vr0.nonnegative_p () && vr4.nonnegative_p ())
@@ -1025,6 +1027,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  /* "X+C" doesn't overflow.  */
  && range_op_handler (PLUS_EXPR).overflow_free_p (vr0, vr1)
  && get_range_query (cfun)->range_of_expr (vr3, @3)
+ && !vr3.undefined_p ()
  /* "X+C" and "X" are not of opposite sign.  */
  && (TYPE_UNSIGNED (type)
  || (vr0.nonnegative_p () && vr3.nonnegative_p ())
diff --git a/gcc/testsuite/gcc.dg/pr111303.c b/gcc/testsuite/gcc.dg/pr111303.c
new file mode 100644
index 000..eaabe55c105
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr111303.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+/* Make sure no ICE. */
+unsigned char a;
+int b(int c) {
+  if (c >= 5000)
+return c / 5;
+}
+void d() { b(a - 5); }
+int main() {}
-- 
2.25.1



Re: [PATCH v3] RISC-V: Add autovec FP binary operations.

2023-09-06 Thread Lehua Ding

Hi Robin,


Yes, you're right, this should not be necessary.  This is more of a
test for the execution environment than the compiler.  I think Juzhe
removed it already in his patch that enables the vector test suite.
In the future we would use the checks that Joern added, not sure if
they are already upstream

All right, let's wait for further action. Thanks.

--
Best,
Lehua



Re: [PATCH] LoongArch: Link c++ header directory in the default ABI to the toplevel.

2023-09-06 Thread Yang Yujie
On Wed, Sep 06, 2023 at 06:38:25PM +0800, Xi Ruoyao wrote:
> On Wed, 2023-09-06 at 18:06 +0800, Yang Yujie wrote:
> > When multilib is enabled, the c++ header directory of the default multilib
> > variant needs to be linked to the toplevel since g++ does not search the
> > toplevel in this case.
> > 
> > libstdc++-v3/ChangeLog:
> > 
> > * configure.host: Register t-loongarch in tmake_file.
> > * config/cpu/loongarch/t-loongarch: New file.  Link c++ header
> > directory in the default ABI to the toplevel.
> > ---
> >  libstdc++-v3/config/cpu/loongarch/t-loongarch | 12 
> >  libstdc++-v3/configure.host   |  5 -
> >  2 files changed, 16 insertions(+), 1 deletion(-)
> >  create mode 100644 libstdc++-v3/config/cpu/loongarch/t-loongarch
> > 
> > diff --git a/libstdc++-v3/config/cpu/loongarch/t-loongarch
> > b/libstdc++-v3/config/cpu/loongarch/t-loongarch
> > new file mode 100644
> > index 000..942eddeb3be
> > --- /dev/null
> > +++ b/libstdc++-v3/config/cpu/loongarch/t-loongarch
> > @@ -0,0 +1,12 @@
> > +LA_DEFAULT_MULTIDIR = $(shell $(CXX) --print-multi-directory)
> > +TOPLEV_HEADERS = 
> > $(DESTDIR)${gxx_include_dir}/${host_alias}/$(LA_DEFAULT_MULTIDIR)
> > +
> > +.PHONY: install-toplevel-link
> > +install: install-toplevel-link
> > +install-toplevel-link:
> > +   if test x$(MULTIDO) != xtrue && \
> > +  test x$(LA_DEFAULT_MULTIDIR) != x.; then \
> > +   $(MKDIR_P) "$(dir $(TOPLEV_HEADERS))"; \
> > +   rm -rf "$(TOPLEV_HEADERS)"; \
> > +   $(LN_S) ../ "$(TOPLEV_HEADERS)"; \
> 
> From autoconf info page:
> 
>  -- Macro: AC_PROG_LN_S
>  If ‘ln -s’ works on the current file system (the operating system
>  and file system support symbolic links), set the output variable
>  ‘LN_S’ to ‘ln -s’; otherwise, if ‘ln’ works, set ‘LN_S’ to ‘ln’,
>  and otherwise set it to ‘cp -pR’.
> 
>  If you make a link in a directory other than the current directory,
>  its meaning depends on whether ‘ln’ or ‘ln -s’ is used.  To safely
>  create links using ‘$(LN_S)’, either find out which form is used
>  and adjust the arguments, or always invoke ‘ln’ in the directory
>  where the link is to be created.
> 
>  In other words, it does not work to do:
>   $(LN_S) foo /x/bar
> 
>  Instead, do:
> 
>   (cd /x && $(LN_S) foo bar)
> 
> But for this special case we cannot "cp -pR ../ $(TOPLEV_HEADERS)"
> either:
> 
> $ cp ../* -pR something
> cp: cannot copy a directory, '../g', into itself, 'h/g'
> 
> So I guess we'll need something like
> 
> if ln -s ../ "$(TOPLEV_HEADERS)"; then
>   # OK!
>   true
> else
>   # system does not support symlink :(
>   # install another copy of toplevel headers into default multilib subdir
>   TODO: 
> fi
> 
> And all libstdc++ patches should Cc: libstd...@gcc.gnu.org.
> 
> > +   fi
> > diff --git a/libstdc++-v3/configure.host b/libstdc++-v3/configure.host
> > index 9e7c7f02dfd..9dc42ad3edb 100644
> > --- a/libstdc++-v3/configure.host
> > +++ b/libstdc++-v3/configure.host
> > @@ -315,7 +315,10 @@ esac
> >  # Set any OS-dependent and CPU-dependent bits.
> >  # THIS TABLE IS SORTED.  KEEP IT THAT WAY.
> >  case "${host}" in
> > -  *-*-linux* | *-*-uclinux*)
> > + loongarch*)
> > +    tmake_file="cpu/loongarch/t-loongarch"
> > +    ;;
> > + *-*-linux* | *-*-uclinux*)
> >  case "${host_cpu}" in
> >    i[567]86)
> >  abi_baseline_pair=i486-linux-gnu
> 
> -- 
> Xi Ruoyao 
> School of Aerospace Science and Technology, Xidian University

Thanks for the review!

After some tweaking, it appeared that we can simply override
${multisubdir} in configure.host and achieve the same.

I will upload another patch soon.

Yujie



Re: [PATCH v1 4/4] LoongArch: Add tests for Loongson SX floating-point conversion instructions.

2023-09-06 Thread chenxiaolong
在 2023-09-06三的 18:56 +0800,Xi Ruoyao写道:
> On Wed, 2023-09-06 at 18:45 +0800, Xiaolong Chen wrote:
> > +  *((int*)& __m128_op0[3]) = 0x004200a0;
> > +  *((int*)& __m128_op0[2]) = 0x;
> > +  *((int*)& __m128_op0[1]) = 0x004200a0;
> > +  *((int*)& __m128_op0[0]) = 0x0021;
> 
> These are aliasing rule violation and they will suddenly blow up when
> GCC optimizer starts to optimize more aggressively based on the
> aliasing
> rule.
> 
> Try not to use these (you can write a helper function to memcpy()
> into a
> __m128).  Or use -fno-strict-alising in dg-options.
> 
Okay, thanks for the tip. After carefully reading the gcc manual, a new
addition -fno-strict-aliasing in dg-options is added.

Thanks.



[PATCH v4] RISC-V:Optimize the MASK opt generation

2023-09-06 Thread Feng Wang
This patch rebases the change of "[PATCH] RISC-V: Optimize the MASK opt
generation" and add the new explanation in the options.texi.
gcc/ChangeLog:

* config/riscv/riscv-opts.h (MASK_ZICSR):
(MASK_ZIFENCEI): Delete;
(MASK_ZIHINTNTL):Ditto;
(MASK_ZIHINTPAUSE):  Ditto;
(TARGET_ZICSR):  Ditto;
(TARGET_ZIFENCEI):   Ditto;
(TARGET_ZIHINTNTL):  Ditto;
(TARGET_ZIHINTPAUSE):Ditto;
(MASK_ZAWRS):Ditto;
(TARGET_ZAWRS):  Ditto;
(MASK_ZBA):  Ditto;
(MASK_ZBB):  Ditto;
(MASK_ZBC):  Ditto;
(MASK_ZBS):  Ditto;
(TARGET_ZBA):Ditto;
(TARGET_ZBB):Ditto;
(TARGET_ZBC):Ditto;
(TARGET_ZBS):Ditto;
(MASK_ZFINX):Ditto;
(MASK_ZDINX):Ditto;
(MASK_ZHINX):Ditto;
(MASK_ZHINXMIN): Ditto;
(TARGET_ZFINX):  Ditto;
(TARGET_ZDINX):  Ditto;
(TARGET_ZHINX):  Ditto;
(TARGET_ZHINXMIN):   Ditto;
(MASK_ZBKB): Ditto;
(MASK_ZBKC): Ditto;
(MASK_ZBKX): Ditto;
(MASK_ZKNE): Ditto;
(MASK_ZKND): Ditto;
(MASK_ZKNH): Ditto;
(MASK_ZKR):  Ditto;
(MASK_ZKSED):Ditto;
(MASK_ZKSH): Ditto;
(MASK_ZKT):  Ditto;
(TARGET_ZBKB):   Ditto;
(TARGET_ZBKC):   Ditto;
(TARGET_ZBKX):   Ditto;
(TARGET_ZKNE):   Ditto;
(TARGET_ZKND):   Ditto;
(TARGET_ZKNH):   Ditto;
(TARGET_ZKR):Ditto;
(TARGET_ZKSED):  Ditto;
(TARGET_ZKSH):   Ditto;
(TARGET_ZKT):Ditto;
(MASK_ZTSO): Ditto;
(TARGET_ZTSO):   Ditto;
(MASK_VECTOR_ELEN_32):   Ditto;
(MASK_VECTOR_ELEN_64):   Ditto;
(MASK_VECTOR_ELEN_FP_32):Ditto;
(MASK_VECTOR_ELEN_FP_64):Ditto;
(MASK_VECTOR_ELEN_FP_16):Ditto;
(TARGET_VECTOR_ELEN_32): Ditto;
(TARGET_VECTOR_ELEN_64): Ditto;
(TARGET_VECTOR_ELEN_FP_32):Ditto;
(TARGET_VECTOR_ELEN_FP_64):Ditto;
(TARGET_VECTOR_ELEN_FP_16):Ditto;
 (MASK_ZVBB):   Ditto;
(MASK_ZVBC):   Ditto;
(TARGET_ZVBB): Ditto;
(TARGET_ZVBC): Ditto;
(MASK_ZVKG):   Ditto;
(MASK_ZVKNED): Ditto;
(MASK_ZVKNHA): Ditto;
(MASK_ZVKNHB): Ditto;
(MASK_ZVKSED): Ditto;
(MASK_ZVKSH):  Ditto;
(MASK_ZVKN):   Ditto;
(MASK_ZVKNC):  Ditto;
(MASK_ZVKNG):  Ditto;
(MASK_ZVKS):   Ditto;
(MASK_ZVKSC):  Ditto;
(MASK_ZVKSG):  Ditto;
(MASK_ZVKT):   Ditto;
(TARGET_ZVKG): Ditto;
(TARGET_ZVKNED):   Ditto;
(TARGET_ZVKNHA):   Ditto;
(TARGET_ZVKNHB):   Ditto;
(TARGET_ZVKSED):   Ditto;
(TARGET_ZVKSH):Ditto;
(TARGET_ZVKN): Ditto;
(TARGET_ZVKNC):Ditto;
(TARGET_ZVKNG):Ditto;
(TARGET_ZVKS): Ditto;
(TARGET_ZVKSC):Ditto;
(TARGET_ZVKSG):Ditto;
(TARGET_ZVKT): Ditto;
(MASK_ZVL32B): Ditto;
(MASK_ZVL64B): Ditto;
(MASK_ZVL128B):Ditto;
(MASK_ZVL256B):Ditto;
(MASK_ZVL512B):Ditto;
(MASK_ZVL1024B):   Ditto;
(MASK_ZVL2048B):   Ditto;
(MASK_ZVL4096B):   Ditto;
(MASK_ZVL8192B):   Ditto;
(MASK_ZVL16384B):  Ditto;
(MASK_ZVL32768B):  Ditto;
(MASK_ZVL65536B):  Ditto;
(TARGET_ZVL32B):   Ditto;
(TARGET_ZVL64B):   Ditto;
(TARGET_ZVL128B):  Ditto;
(TARGET_ZVL256B):  Ditto;
(TARGET_ZVL512B):  Ditto;
(TARGET_ZVL1024B): Ditto;
(TARGET_ZVL2048B): Ditto;
(TARGET_ZVL4096B): Ditto;
(TARGET_ZVL8192B): Ditto;
(TARGET_ZVL16384B):Ditto;
(TARGET_ZVL32768B):Ditto;
(TARGET_ZVL65536B):Ditto;
(MASK_ZICBOZ): Ditto;
(MASK_ZICBOM): Ditto;
(MASK_ZICBOP): Ditto;
(TARGET_ZICBOZ):   Ditto;
(TARGET_ZICBOM):   Ditto;
(TARGET_ZICBOP):   Ditto;
(MASK_ZICOND): Ditto;
(TARGET_ZICOND):   Ditto;
(MASK_ZFA):Ditto;
(TARGET_ZFA):  Ditto;
(MASK_ZFHMIN): Ditto;
(MASK_ZFH):Ditto;
(MASK_ZVFHMIN):Ditto;
(MASK_ZVFH):   Ditto;
(TARGET_ZFHMIN):   Ditto;
(TARGET_ZFH):  Ditto;
(TARGET_ZVFHMIN):  Ditto;
  

[RFC PATCH 2/2] RISC-V: Update testsuite for type-changed builtins

2023-09-06 Thread Tsukasa OI via Gcc-patches
From: Tsukasa OI 

This commit replaces the type of the builtin used in the testsuite.

Even without this commit, it won't cause any test failures but changed so
that no confusion occurs.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/zbc32.c: Make signed type to unsigned.
* gcc.target/riscv/zbc64.c: Ditto.
* gcc.target/riscv/zbkb32.c: Ditto.
* gcc.target/riscv/zbkb64.c: Ditto.
* gcc.target/riscv/zbkc32.c: Ditto.
* gcc.target/riscv/zbkc64.c: Ditto.
* gcc.target/riscv/zbkx32.c: Ditto.
* gcc.target/riscv/zbkx64.c: Ditto.
* gcc.target/riscv/zknd32.c: Ditto.
* gcc.target/riscv/zknd64.c: Ditto.
* gcc.target/riscv/zkne32.c: Ditto.
* gcc.target/riscv/zkne64.c: Ditto.
* gcc.target/riscv/zknh-sha256.c: Ditto.
* gcc.target/riscv/zknh-sha512-32.c: Ditto.
* gcc.target/riscv/zknh-sha512-64.c: Ditto.
* gcc.target/riscv/zksed32.c: Ditto.
* gcc.target/riscv/zksed64.c: Ditto.
* gcc.target/riscv/zksh32.c: Ditto.
* gcc.target/riscv/zksh64.c: Ditto.
---
 gcc/testsuite/gcc.target/riscv/zbc32.c  |  6 +++---
 gcc/testsuite/gcc.target/riscv/zbc64.c  |  6 +++---
 gcc/testsuite/gcc.target/riscv/zbkb32.c | 10 +-
 gcc/testsuite/gcc.target/riscv/zbkb64.c |  8 
 gcc/testsuite/gcc.target/riscv/zbkc32.c |  4 ++--
 gcc/testsuite/gcc.target/riscv/zbkc64.c |  4 ++--
 gcc/testsuite/gcc.target/riscv/zbkx32.c |  4 ++--
 gcc/testsuite/gcc.target/riscv/zbkx64.c |  4 ++--
 gcc/testsuite/gcc.target/riscv/zknd32.c |  4 ++--
 gcc/testsuite/gcc.target/riscv/zknd64.c | 10 +-
 gcc/testsuite/gcc.target/riscv/zkne32.c |  4 ++--
 gcc/testsuite/gcc.target/riscv/zkne64.c |  8 
 gcc/testsuite/gcc.target/riscv/zknh-sha256.c|  8 
 gcc/testsuite/gcc.target/riscv/zknh-sha512-32.c | 12 ++--
 gcc/testsuite/gcc.target/riscv/zknh-sha512-64.c |  8 
 gcc/testsuite/gcc.target/riscv/zksed32.c|  4 ++--
 gcc/testsuite/gcc.target/riscv/zksed64.c|  4 ++--
 gcc/testsuite/gcc.target/riscv/zksh32.c |  4 ++--
 gcc/testsuite/gcc.target/riscv/zksh64.c |  4 ++--
 19 files changed, 58 insertions(+), 58 deletions(-)

diff --git a/gcc/testsuite/gcc.target/riscv/zbc32.c 
b/gcc/testsuite/gcc.target/riscv/zbc32.c
index 08705c4a687e..f3fb2238f7f4 100644
--- a/gcc/testsuite/gcc.target/riscv/zbc32.c
+++ b/gcc/testsuite/gcc.target/riscv/zbc32.c
@@ -3,17 +3,17 @@
 /* { dg-skip-if "" { *-*-* } { "-g" "-flto"} } */
 #include 
 
-int32_t foo1(int32_t rs1, int32_t rs2)
+uint32_t foo1(uint32_t rs1, uint32_t rs2)
 {
 return __builtin_riscv_clmul(rs1, rs2);
 }
 
-int32_t foo2(int32_t rs1, int32_t rs2)
+uint32_t foo2(uint32_t rs1, uint32_t rs2)
 {
 return __builtin_riscv_clmulh(rs1, rs2);
 }
 
-int32_t foo3(int32_t rs1, int32_t rs2)
+uint32_t foo3(uint32_t rs1, uint32_t rs2)
 {
 return __builtin_riscv_clmulr(rs1, rs2);
 }
diff --git a/gcc/testsuite/gcc.target/riscv/zbc64.c 
b/gcc/testsuite/gcc.target/riscv/zbc64.c
index a19f42b2883f..841a0aa7847d 100644
--- a/gcc/testsuite/gcc.target/riscv/zbc64.c
+++ b/gcc/testsuite/gcc.target/riscv/zbc64.c
@@ -3,17 +3,17 @@
 /* { dg-skip-if "" { *-*-* } { "-g" "-flto"} } */
 #include 
 
-int64_t foo1(int64_t rs1, int64_t rs2)
+uint64_t foo1(uint64_t rs1, uint64_t rs2)
 {
 return __builtin_riscv_clmul(rs1, rs2);
 }
 
-int64_t foo2(int64_t rs1, int64_t rs2)
+uint64_t foo2(uint64_t rs1, uint64_t rs2)
 {
 return __builtin_riscv_clmulh(rs1, rs2);
 }
 
-int64_t foo3(int64_t rs1, int64_t rs2)
+uint64_t foo3(uint64_t rs1, uint64_t rs2)
 {
 return __builtin_riscv_clmulr(rs1, rs2);
 }
diff --git a/gcc/testsuite/gcc.target/riscv/zbkb32.c 
b/gcc/testsuite/gcc.target/riscv/zbkb32.c
index dd45b8b9dc72..b2e442dc49d8 100644
--- a/gcc/testsuite/gcc.target/riscv/zbkb32.c
+++ b/gcc/testsuite/gcc.target/riscv/zbkb32.c
@@ -4,27 +4,27 @@
 
 #include 
 
-int32_t foo1(int16_t rs1, int16_t rs2)
+uint32_t foo1(uint16_t rs1, uint16_t rs2)
 {
 return __builtin_riscv_pack(rs1, rs2);
 }
 
-int32_t foo2(int8_t rs1, int8_t rs2)
+uint32_t foo2(uint8_t rs1, uint8_t rs2)
 {
 return __builtin_riscv_packh(rs1, rs2);
 }
 
-int32_t foo3(int32_t rs1)
+uint32_t foo3(uint32_t rs1)
 {
 return __builtin_riscv_brev8(rs1);
 }
 
-int32_t foo4(int32_t rs1)
+uint32_t foo4(uint32_t rs1)
 {
 return __builtin_riscv_zip(rs1);
 }
 
-int32_t foo5(int32_t rs1)
+uint32_t foo5(uint32_t rs1)
 {
 return __builtin_riscv_unzip(rs1);
 }
diff --git a/gcc/testsuite/gcc.target/riscv/zbkb64.c 
b/gcc/testsuite/gcc.target/riscv/zbkb64.c
index 960a2ae30ed6..08ac9c2a9f00 100644
--- a/gcc/testsuite/gcc.target/riscv/zbkb64.c
+++ b/gcc/testsuite/gcc.target/riscv/zbkb64.c
@@ -3,22 +3,22 @@
 /* { dg-skip-if "" { *-*-* } { "-g" "-flto"} } */
 #include 
 
-int64_t foo1(int32_t rs1, int32_t rs2)
+uint64_t foo1(uint32_t rs1, uint32_t rs2)
 {
 return 

[RFC PATCH 1/2] RISC-V: Make bit manipulation value / round number and shift amount types for builtins unsigned

2023-09-06 Thread Tsukasa OI via Gcc-patches
From: Tsukasa OI 

For bit manipulation operations, inputs and the manipulated output are
better to be unsigned like other target-independent builtins like
__builtin_bswap32 and __builtin_popcount.

Although this is not completely compatible as before (as the type changes),
most code will run normally, even without warnings (with -Wall -Wextra).

Round numbers and shift amount on the scalar crypto instructions are
changed to unsigned in parity with LLVM 17 commit 599421ae36c3
("[RISCV] Use unsigned instead of signed types for Zk* and Zb* builtins.").

gcc/ChangeLog:

* config/riscv/riscv-builtins.cc (RISCV_ATYPE_UQI): New for
uint8_t.  (RISCV_ATYPE_UHI): New for uint16_t.
(RISCV_ATYPE_QI, RISCV_ATYPE_HI, RISCV_ATYPE_SI, RISCV_ATYPE_DI):
Removed as no longer used.
(RISCV_ATYPE_UDI): New for uint64_t.
* config/riscv/riscv-cmo.def: Make types unsigned for not working
"zicbop_cbo_prefetchi" and working bit manipulation clmul builtin
argument/return types.
* config/riscv/riscv-ftypes.def: Make bit manipulation, round
number and shift amount types unsigned.
* config/riscv/riscv-scalar-crypto.def: Ditto.
---
 gcc/config/riscv/riscv-builtins.cc   |   7 +-
 gcc/config/riscv/riscv-cmo.def   |  16 ++--
 gcc/config/riscv/riscv-ftypes.def|  24 +++---
 gcc/config/riscv/riscv-scalar-crypto.def | 104 +++
 4 files changed, 75 insertions(+), 76 deletions(-)

diff --git a/gcc/config/riscv/riscv-builtins.cc 
b/gcc/config/riscv/riscv-builtins.cc
index 8afe7b7e97d3..f6b06b3c16ac 100644
--- a/gcc/config/riscv/riscv-builtins.cc
+++ b/gcc/config/riscv/riscv-builtins.cc
@@ -155,11 +155,10 @@ AVAIL (hint_pause, (!0))
 
 /* Argument types.  */
 #define RISCV_ATYPE_VOID void_type_node
+#define RISCV_ATYPE_UQI unsigned_intQI_type_node
+#define RISCV_ATYPE_UHI unsigned_intHI_type_node
 #define RISCV_ATYPE_USI unsigned_intSI_type_node
-#define RISCV_ATYPE_QI intQI_type_node
-#define RISCV_ATYPE_HI intHI_type_node
-#define RISCV_ATYPE_SI intSI_type_node
-#define RISCV_ATYPE_DI intDI_type_node
+#define RISCV_ATYPE_UDI unsigned_intDI_type_node
 #define RISCV_ATYPE_VOID_PTR ptr_type_node
 
 /* RISCV_FTYPE_ATYPESN takes N RISCV_FTYPES-like type codes and lists
diff --git a/gcc/config/riscv/riscv-cmo.def b/gcc/config/riscv/riscv-cmo.def
index b92044dc6ff9..ff713b78e19e 100644
--- a/gcc/config/riscv/riscv-cmo.def
+++ b/gcc/config/riscv/riscv-cmo.def
@@ -13,15 +13,15 @@ RISCV_BUILTIN (zero_si, "zicboz_cbo_zero", 
RISCV_BUILTIN_DIRECT_NO_TARGET, RISCV
 RISCV_BUILTIN (zero_di, "zicboz_cbo_zero", RISCV_BUILTIN_DIRECT_NO_TARGET, 
RISCV_VOID_FTYPE_VOID_PTR, zero64),
 
 // zicbop
-RISCV_BUILTIN (prefetchi_si, "zicbop_cbo_prefetchi", RISCV_BUILTIN_DIRECT, 
RISCV_SI_FTYPE_SI, prefetchi32),
-RISCV_BUILTIN (prefetchi_di, "zicbop_cbo_prefetchi", RISCV_BUILTIN_DIRECT, 
RISCV_DI_FTYPE_DI, prefetchi64),
+RISCV_BUILTIN (prefetchi_si, "zicbop_cbo_prefetchi", RISCV_BUILTIN_DIRECT, 
RISCV_USI_FTYPE_USI, prefetchi32),
+RISCV_BUILTIN (prefetchi_di, "zicbop_cbo_prefetchi", RISCV_BUILTIN_DIRECT, 
RISCV_UDI_FTYPE_UDI, prefetchi64),
 
 // zbkc or zbc
-RISCV_BUILTIN (clmul_si, "clmul", RISCV_BUILTIN_DIRECT, RISCV_SI_FTYPE_SI_SI, 
clmul_zbkc32_or_zbc32),
-RISCV_BUILTIN (clmul_di, "clmul", RISCV_BUILTIN_DIRECT, RISCV_DI_FTYPE_DI_DI, 
clmul_zbkc64_or_zbc64),
-RISCV_BUILTIN (clmulh_si, "clmulh", RISCV_BUILTIN_DIRECT, 
RISCV_SI_FTYPE_SI_SI, clmul_zbkc32_or_zbc32),
-RISCV_BUILTIN (clmulh_di, "clmulh", RISCV_BUILTIN_DIRECT, 
RISCV_DI_FTYPE_DI_DI, clmul_zbkc64_or_zbc64),
+RISCV_BUILTIN (clmul_si, "clmul", RISCV_BUILTIN_DIRECT, 
RISCV_USI_FTYPE_USI_USI, clmul_zbkc32_or_zbc32),
+RISCV_BUILTIN (clmul_di, "clmul", RISCV_BUILTIN_DIRECT, 
RISCV_UDI_FTYPE_UDI_UDI, clmul_zbkc64_or_zbc64),
+RISCV_BUILTIN (clmulh_si, "clmulh", RISCV_BUILTIN_DIRECT, 
RISCV_USI_FTYPE_USI_USI, clmul_zbkc32_or_zbc32),
+RISCV_BUILTIN (clmulh_di, "clmulh", RISCV_BUILTIN_DIRECT, 
RISCV_UDI_FTYPE_UDI_UDI, clmul_zbkc64_or_zbc64),
 
 // zbc
-RISCV_BUILTIN (clmulr_si, "clmulr", RISCV_BUILTIN_DIRECT, 
RISCV_SI_FTYPE_SI_SI, clmulr_zbc32),
-RISCV_BUILTIN (clmulr_di, "clmulr", RISCV_BUILTIN_DIRECT, 
RISCV_DI_FTYPE_DI_DI, clmulr_zbc64),
+RISCV_BUILTIN (clmulr_si, "clmulr", RISCV_BUILTIN_DIRECT, 
RISCV_USI_FTYPE_USI_USI, clmulr_zbc32),
+RISCV_BUILTIN (clmulr_di, "clmulr", RISCV_BUILTIN_DIRECT, 
RISCV_UDI_FTYPE_UDI_UDI, clmulr_zbc64),
diff --git a/gcc/config/riscv/riscv-ftypes.def 
b/gcc/config/riscv/riscv-ftypes.def
index 3b518195a29c..366861ce640e 100644
--- a/gcc/config/riscv/riscv-ftypes.def
+++ b/gcc/config/riscv/riscv-ftypes.def
@@ -30,15 +30,15 @@ DEF_RISCV_FTYPE (0, (USI))
 DEF_RISCV_FTYPE (0, (VOID))
 DEF_RISCV_FTYPE (1, (VOID, USI))
 DEF_RISCV_FTYPE (1, (VOID, VOID_PTR))
-DEF_RISCV_FTYPE (1, (SI, SI))
-DEF_RISCV_FTYPE (1, (DI, DI))
-DEF_RISCV_FTYPE (2, (SI, QI, QI))
-DEF_RISCV_FTYPE (2, (SI, HI, HI))
-DEF_RISCV_FTYPE (2, (SI, SI, SI))
-DEF_RISCV_FTYPE (2, (DI, QI, QI))
-DEF_RISCV_FTYPE 

[RFC PATCH 0/2] RISC-V: Change RISC-V bit manipulation / scalar crypto builtin types

2023-09-06 Thread Tsukasa OI via Gcc-patches
Hello,

Many RISC-V builtins operate in signed integer types but in many cases,
they are better to be unsigned.

There are a few reasons to do that:

1.  Being more natural
For bit manipulation operations, the direct input and the result should
have an unsigned type.
e.g. __builtin_bswap16
Both input and output should be (and are) unsigned.
e.g. __builtin_popcount
The input should be (and is) unsigned.
The output is a bit count and is in int (signed integer).
2.  In parity with LLVM 17
LLVM made similar changes to this patch set in commit 599421ae36c3
("[RISCV] Use unsigned instead of signed types for Zk* and Zb*
builtins.") by Craig Topper.
Note that shift amount / round number argument types are changed to
unsigned in this LLVM commit, I did the same.
3.  Minimum compatibility breakage
This change rarely causes warnings even if both -Wall and -Wextra are
specified.  In fact, only applying PATCH 1/2 does not cause any
additional test failures.  PATCH 2/2 only contains testsuite changes
(uses correct types as the builtin uses).

But not completely compatible.  For instance, we will notice when operating
with for instance C++'s "auto" / "decltype" or overload resolution.

So, I would like to hear your thoughts first.

Note that, the only reason I separated this RFC patch set to two patches
is to demonstrate that no additional warnings occur even if only PATCH 1/2
is applied.  If approved or leaves an RFC PATCH, both will be merged.


p.s.

LLVM has another type of different builtin types (with the same name),
scalar cryptography builtins that operate in 32-bit integers, not XLEN-
specific (applies to SHA-256, SM3 and SM4).  For those cases, GCC prefers
XLEN-specific integer type but LLVM 17 always prefers uint32_t.

This is a result of LLVM commit 599421ae36c3 ("[RISCV] Re-define sha256,
Zksed, and Zksh intrinsics to use i32 types.").

Because just changing the width causes errors on GCC, even if I change them
to uint32_t, that would be in a different patch set.


Sincerely,
Tsukasa




Tsukasa OI (2):
  RISC-V: Make bit manipulation value / round number and shift amount
types for builtins unsigned
  RISC-V: Update testsuite for type-changed builtins

 gcc/config/riscv/riscv-builtins.cc|   7 +-
 gcc/config/riscv/riscv-cmo.def|  16 +--
 gcc/config/riscv/riscv-ftypes.def |  24 ++--
 gcc/config/riscv/riscv-scalar-crypto.def  | 104 +-
 gcc/testsuite/gcc.target/riscv/zbc32.c|   6 +-
 gcc/testsuite/gcc.target/riscv/zbc64.c|   6 +-
 gcc/testsuite/gcc.target/riscv/zbkb32.c   |  10 +-
 gcc/testsuite/gcc.target/riscv/zbkb64.c   |   8 +-
 gcc/testsuite/gcc.target/riscv/zbkc32.c   |   4 +-
 gcc/testsuite/gcc.target/riscv/zbkc64.c   |   4 +-
 gcc/testsuite/gcc.target/riscv/zbkx32.c   |   4 +-
 gcc/testsuite/gcc.target/riscv/zbkx64.c   |   4 +-
 gcc/testsuite/gcc.target/riscv/zknd32.c   |   4 +-
 gcc/testsuite/gcc.target/riscv/zknd64.c   |  10 +-
 gcc/testsuite/gcc.target/riscv/zkne32.c   |   4 +-
 gcc/testsuite/gcc.target/riscv/zkne64.c   |   8 +-
 gcc/testsuite/gcc.target/riscv/zknh-sha256.c  |   8 +-
 .../gcc.target/riscv/zknh-sha512-32.c |  12 +-
 .../gcc.target/riscv/zknh-sha512-64.c |   8 +-
 gcc/testsuite/gcc.target/riscv/zksed32.c  |   4 +-
 gcc/testsuite/gcc.target/riscv/zksed64.c  |   4 +-
 gcc/testsuite/gcc.target/riscv/zksh32.c   |   4 +-
 gcc/testsuite/gcc.target/riscv/zksh64.c   |   4 +-
 23 files changed, 133 insertions(+), 134 deletions(-)


base-commit: af88776caa20342482b11ccb580742a46c621250
-- 
2.42.0



Re: [PATCH] LoongArch: Use bstrins instruction for (a & ~mask) and (a & mask) | (b & ~mask) [PR111252]

2023-09-06 Thread chenglulu



在 2023/9/6 下午6:58, Xi Ruoyao 写道:

Forgot to mention: I've bootstrapped and regtested this patch on
loongarch64-linux-gnu (with PR110939 patch applied to unbreak the
bootstrapping).  Ok for trunk?


LGTM!

Thanks!



On Wed, 2023-09-06 at 18:46 +0800, Xi Ruoyao wrote:


If mask is a constant with value ((1 << N) - 1) << M we can perform this
optimization.

gcc/ChangeLog:

 PR target/111252
 * config/loongarch/loongarch-protos.h
 (loongarch_pre_reload_split): Declare new function.
 (loongarch_use_bstrins_for_ior_with_mask): Likewise.
 * config/loongarch/loongarch.cc
 (loongarch_pre_reload_split): Implement.
 (loongarch_use_bstrins_for_ior_with_mask): Likewise.
 * config/loongarch/predicates.md (ins_zero_bitmask_operand):
 New predicate.
 * config/loongarch/loongarch.md (bstrins__for_mask):
 New define_insn_and_split.
 (bstrins__for_ior_mask): Likewise.
 (define_peephole2): Further optimize code sequence produced by
 bstrins__for_ior_mask if possible.

gcc/testsuite/ChangeLog:

 * g++.target/loongarch/bstrins-compile.C: New test.
 * g++.target/loongarch/bstrins-run.C: New test.

/* snip */





[PATCH] Support vpermw/vpermi2w/vpermt2w instructions for vector HF/BFmodes.

2023-09-06 Thread liuhongt via Gcc-patches
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready push to trunk.

gcc/ChangeLog:

* config/i386/sse.md
(_vpermt2var3): New define_insn.
(VHFBF_AVX512VL): New mode iterator.
(VI2HFBF_AVX512VL): New mode iterator.
---
 gcc/config/i386/sse.md | 32 
 1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 6d3ae8dea0c..12fe97951ee 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -466,6 +466,10 @@ (define_mode_iterator VHFBF_128 [V8HF V8BF])
 (define_mode_iterator VHF_AVX512VL
   [V32HF (V16HF "TARGET_AVX512VL") (V8HF "TARGET_AVX512VL")])
 
+(define_mode_iterator VHFBF_AVX512VL
+  [V32HF (V16HF "TARGET_AVX512VL") (V8HF "TARGET_AVX512VL")
+   V32BF (V16BF "TARGET_AVX512VL") (V8BF "TARGET_AVX512VL")])
+
 ;; All vector integer modes
 (define_mode_iterator VI
   [(V16SI "TARGET_AVX512F") (V8DI "TARGET_AVX512F")
@@ -565,6 +569,11 @@ (define_mode_iterator VI48_AVX512F_AVX512VL
 (define_mode_iterator VI2_AVX512VL
   [(V8HI "TARGET_AVX512VL") (V16HI "TARGET_AVX512VL") V32HI])
 
+(define_mode_iterator VI2HFBF_AVX512VL
+  [(V8HI "TARGET_AVX512VL") (V16HI "TARGET_AVX512VL") V32HI
+   (V8HF "TARGET_AVX512VL") (V16HF "TARGET_AVX512VL") V32HF
+   (V8BF "TARGET_AVX512VL") (V16BF "TARGET_AVX512VL") V32BF])
+
 (define_mode_iterator VI2H_AVX512VL
   [(V8HI "TARGET_AVX512VL") (V16HI "TARGET_AVX512VL") V32HI
(V8SI "TARGET_AVX512VL") V16SI
@@ -26110,13 +26119,13 @@ (define_insn "_permvar"
(set_attr "mode" "")])
 
 (define_insn "_permvar"
-  [(set (match_operand:VI2_AVX512VL 0 "register_operand" "=v")
-   (unspec:VI2_AVX512VL
- [(match_operand:VI2_AVX512VL 1 "nonimmediate_operand" "vm")
+  [(set (match_operand:VI2HFBF_AVX512VL 0 "register_operand" "=v")
+   (unspec:VI2HFBF_AVX512VL
+ [(match_operand:VI2HFBF_AVX512VL 1 "nonimmediate_operand" "vm")
   (match_operand: 2 "register_operand" "v")]
  UNSPEC_VPERMVAR))]
   "TARGET_AVX512BW && "
-  "vperm\t{%1, %2, %0|%0, %2, %1}"
+  "vpermw\t{%1, %2, %0|%0, %2, %1}"
   [(set_attr "type" "sselog")
(set_attr "prefix" "")
(set_attr "mode" "")])
@@ -26987,6 +26996,21 @@ (define_insn 
"_vpermt2var3"
(set_attr "prefix" "evex")
(set_attr "mode" "")])
 
+(define_insn "_vpermt2var3"
+  [(set (match_operand:VHFBF_AVX512VL 0 "register_operand" "=v,v")
+   (unspec:VHFBF_AVX512VL
+ [(match_operand: 1 "register_operand" "v,0")
+  (match_operand:VHFBF_AVX512VL 2 "register_operand" "0,v")
+  (match_operand:VHFBF_AVX512VL 3 "nonimmediate_operand" "vm,vm")]
+ UNSPEC_VPERMT2))]
+  "TARGET_AVX512BW"
+  "@
+   vpermt2w\t{%3, %1, %0|%0, %1, %3}
+   vpermi2w\t{%3, %2, %0|%0, %2, %3}"
+  [(set_attr "type" "sselog")
+   (set_attr "prefix" "evex")
+   (set_attr "mode" "")])
+
 (define_insn "_vpermt2var3_mask"
   [(set (match_operand:VPERMI2 0 "register_operand" "=v")
(vec_merge:VPERMI2
-- 
2.31.1



Re: [PATCH v1 1/4] LoongArch: Add tests of -mstrict-align option.

2023-09-06 Thread chenglulu



在 2023/9/6 下午7:10, Xi Ruoyao 写道:

On Wed, 2023-09-06 at 18:43 +0800, Xiaolong Chen wrote:

gcc/testsuite/ChangeLog:

 * gcc.target/loongarch/strict-align.c: New test.

A question: is there really a CPU model with LSX/LASX but without
unaligned access support?  If not I think we'd just reject -mstrict-
align -mlsx.

Currently Glibc assumes if LSX is available then unaligned access must
be available too.


This is not a question of support or unsupport, the original intention 
is to need to naturally align memory access to improve performance after 
enabling LSX, but this part of the code has not been ported to the main 
branch, so we will submit this test example after adding the 
corresponding function.


Thanks!




---
  gcc/testsuite/gcc.target/loongarch/strict-align.c | 13 +
  1 file changed, 13 insertions(+)
  create mode 100644 gcc/testsuite/gcc.target/loongarch/strict-align.c

diff --git a/gcc/testsuite/gcc.target/loongarch/strict-align.c
b/gcc/testsuite/gcc.target/loongarch/strict-align.c
new file mode 100644
index 000..bcad2b84f68
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/strict-align.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-Ofast -mstrict-align -mlasx" } */
+/* { dg-final { scan-assembler-not "vfadd.s" } } */
+
+void
+foo (float* restrict x, float* restrict y)
+{
+  x[0] = x[0] + y[0];
+  x[1] = x[1] + y[1];
+  x[2] = x[2] + y[2];
+  x[3] = x[3] + y[3];
+}
+




Re: Re: [PATCH v3] RISC-V:Optimize the MASK opt generation

2023-09-06 Thread Feng Wang
Thanks reminder, I should rebase again.
--
Feng Wang
>Hi,
>
>I will need to notify you that x_riscv_xventana_subext,
>MASK_XVENTANACONDOPS and TARGET_XVENTANACONDOPS are added (I think you
>want to rewrite those definitions like the rest).  Also, be careful not
>to remove TARGET_ZICOND_LIKE.
>
>Thanks,
>Tsukasa
>
>On 2023/09/06 11:02, Feng Wang wrote:
>> This patch rebases the change of "[PATCH] RISC-V: Optimize the MASK opt
>> generation" and add the new explanation in the options.texi.
>> Please check the detail info on the
>> "https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg302295.html;
>> gcc/ChangeLog:
>>
>> * config/riscv/riscv-opts.h (MASK_ZICSR):
>> (MASK_ZIFENCEI): Delete;
>> (MASK_ZIHINTNTL):    Ditto;
>> (MASK_ZIHINTPAUSE):  Ditto;
>> (TARGET_ZICSR):  Ditto;
>> (TARGET_ZIFENCEI):   Ditto;
>> (TARGET_ZIHINTNTL):  Ditto;
>> (TARGET_ZIHINTPAUSE):Ditto;
>> (MASK_ZAWRS):    Ditto;
>> (TARGET_ZAWRS):  Ditto;
>> (MASK_ZBA):  Ditto;
>> (MASK_ZBB):  Ditto;
>> (MASK_ZBC):  Ditto;
>> (MASK_ZBS):  Ditto;
>> (TARGET_ZBA):    Ditto;
>> (TARGET_ZBB):    Ditto;
>> (TARGET_ZBC):    Ditto;
>> (TARGET_ZBS):    Ditto;
>> (MASK_ZFINX):    Ditto;
>> (MASK_ZDINX):    Ditto;
>> (MASK_ZHINX):    Ditto;
>> (MASK_ZHINXMIN): Ditto;
>> (TARGET_ZFINX):  Ditto;
>> (TARGET_ZDINX):  Ditto;
>> (TARGET_ZHINX):  Ditto;
>> (TARGET_ZHINXMIN):   Ditto;
>> (MASK_ZBKB): Ditto;
>> (MASK_ZBKC): Ditto;
>> (MASK_ZBKX): Ditto;
>> (MASK_ZKNE): Ditto;
>> (MASK_ZKND): Ditto;
>> (MASK_ZKNH): Ditto;
>> (MASK_ZKR):  Ditto;
>> (MASK_ZKSED):    Ditto;
>> (MASK_ZKSH): Ditto;
>> (MASK_ZKT):  Ditto;
>> (TARGET_ZBKB):   Ditto;
>> (TARGET_ZBKC):   Ditto;
>> (TARGET_ZBKX):   Ditto;
>> (TARGET_ZKNE):   Ditto;
>> (TARGET_ZKND):   Ditto;
>> (TARGET_ZKNH):   Ditto;
>> (TARGET_ZKR):    Ditto;
>> (TARGET_ZKSED):  Ditto;
>> (TARGET_ZKSH):   Ditto;
>> (TARGET_ZKT):    Ditto;
>> (MASK_ZTSO): Ditto;
>> (TARGET_ZTSO):   Ditto;
>> (MASK_VECTOR_ELEN_32):   Ditto;
>> (MASK_VECTOR_ELEN_64):   Ditto;
>> (MASK_VECTOR_ELEN_FP_32):Ditto;
>> (MASK_VECTOR_ELEN_FP_64):Ditto;
>> (MASK_VECTOR_ELEN_FP_16):Ditto;
>> (TARGET_VECTOR_ELEN_32): Ditto;
>> (TARGET_VECTOR_ELEN_64): Ditto;
>> (TARGET_VECTOR_ELEN_FP_32):Ditto;
>> (TARGET_VECTOR_ELEN_FP_64):Ditto;
>> (TARGET_VECTOR_ELEN_FP_16):Ditto;
>>  (MASK_ZVBB):   Ditto;
>> (MASK_ZVBC):   Ditto;
>> (TARGET_ZVBB): Ditto;
>> (TARGET_ZVBC): Ditto;
>> (MASK_ZVKG):   Ditto;
>> (MASK_ZVKNED): Ditto;
>> (MASK_ZVKNHA): Ditto;
>> (MASK_ZVKNHB): Ditto;
>> (MASK_ZVKSED): Ditto;
>> (MASK_ZVKSH):  Ditto;
>> (MASK_ZVKN):   Ditto;
>> (MASK_ZVKNC):  Ditto;
>> (MASK_ZVKNG):  Ditto;
>> (MASK_ZVKS):   Ditto;
>> (MASK_ZVKSC):  Ditto;
>> (MASK_ZVKSG):  Ditto;
>> (MASK_ZVKT):   Ditto;
>> (TARGET_ZVKG): Ditto;
>> (TARGET_ZVKNED):   Ditto;
>> (TARGET_ZVKNHA):   Ditto;
>> (TARGET_ZVKNHB):   Ditto;
>> (TARGET_ZVKSED):   Ditto;
>> (TARGET_ZVKSH):    Ditto;
>> (TARGET_ZVKN): Ditto;
>> (TARGET_ZVKNC):    Ditto;
>> (TARGET_ZVKNG):    Ditto;
>> (TARGET_ZVKS): Ditto;
>> (TARGET_ZVKSC):    Ditto;
>> (TARGET_ZVKSG):    Ditto;
>> (TARGET_ZVKT): Ditto;
>> (MASK_ZVL32B): Ditto;
>> (MASK_ZVL64B): Ditto;
>> (MASK_ZVL128B):    Ditto;
>> (MASK_ZVL256B):    Ditto;
>> (MASK_ZVL512B):    Ditto;
>> (MASK_ZVL1024B):   Ditto;
>> (MASK_ZVL2048B):   Ditto;
>> (MASK_ZVL4096B):   Ditto;
>> (MASK_ZVL8192B):   Ditto;
>> (MASK_ZVL16384B):  Ditto;
>> (MASK_ZVL32768B):  Ditto;
>> (MASK_ZVL65536B):  Ditto;
>> (TARGET_ZVL32B):   Ditto;
>> (TARGET_ZVL64B):   Ditto;
>> (TARGET_ZVL128B):  Ditto;
>> (TARGET_ZVL256B):  Ditto;
>> (TARGET_ZVL512B):  Ditto;
>> (TARGET_ZVL1024B): Ditto;
>> (TARGET_ZVL2048B): Ditto;
>> 

Re: [PATCH v3] RISC-V:Optimize the MASK opt generation

2023-09-06 Thread Tsukasa OI via Gcc-patches
Hi,

I will need to notify you that x_riscv_xventana_subext,
MASK_XVENTANACONDOPS and TARGET_XVENTANACONDOPS are added (I think you
want to rewrite those definitions like the rest).  Also, be careful not
to remove TARGET_ZICOND_LIKE.

Thanks,
Tsukasa

On 2023/09/06 11:02, Feng Wang wrote:
> This patch rebases the change of "[PATCH] RISC-V: Optimize the MASK opt
> generation" and add the new explanation in the options.texi.
> Please check the detail info on the
> "https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg302295.html;
> gcc/ChangeLog:
> 
> * config/riscv/riscv-opts.h (MASK_ZICSR):
> (MASK_ZIFENCEI): Delete;
> (MASK_ZIHINTNTL):Ditto;
> (MASK_ZIHINTPAUSE):  Ditto;
> (TARGET_ZICSR):  Ditto;
> (TARGET_ZIFENCEI):   Ditto;
> (TARGET_ZIHINTNTL):  Ditto;
> (TARGET_ZIHINTPAUSE):Ditto;
> (MASK_ZAWRS):Ditto;
> (TARGET_ZAWRS):  Ditto;
> (MASK_ZBA):  Ditto;
> (MASK_ZBB):  Ditto;
> (MASK_ZBC):  Ditto;
> (MASK_ZBS):  Ditto;
> (TARGET_ZBA):Ditto;
> (TARGET_ZBB):Ditto;
> (TARGET_ZBC):Ditto;
> (TARGET_ZBS):Ditto;
> (MASK_ZFINX):Ditto;
> (MASK_ZDINX):Ditto;
> (MASK_ZHINX):Ditto;
> (MASK_ZHINXMIN): Ditto;
> (TARGET_ZFINX):  Ditto;
> (TARGET_ZDINX):  Ditto;
> (TARGET_ZHINX):  Ditto;
> (TARGET_ZHINXMIN):   Ditto;
> (MASK_ZBKB): Ditto;
> (MASK_ZBKC): Ditto;
> (MASK_ZBKX): Ditto;
> (MASK_ZKNE): Ditto;
> (MASK_ZKND): Ditto;
> (MASK_ZKNH): Ditto;
> (MASK_ZKR):  Ditto;
> (MASK_ZKSED):Ditto;
> (MASK_ZKSH): Ditto;
> (MASK_ZKT):  Ditto;
> (TARGET_ZBKB):   Ditto;
> (TARGET_ZBKC):   Ditto;
> (TARGET_ZBKX):   Ditto;
> (TARGET_ZKNE):   Ditto;
> (TARGET_ZKND):   Ditto;
> (TARGET_ZKNH):   Ditto;
> (TARGET_ZKR):Ditto;
> (TARGET_ZKSED):  Ditto;
> (TARGET_ZKSH):   Ditto;
> (TARGET_ZKT):Ditto;
> (MASK_ZTSO): Ditto;
> (TARGET_ZTSO):   Ditto;
> (MASK_VECTOR_ELEN_32):   Ditto;
> (MASK_VECTOR_ELEN_64):   Ditto;
> (MASK_VECTOR_ELEN_FP_32):Ditto;
> (MASK_VECTOR_ELEN_FP_64):Ditto;
> (MASK_VECTOR_ELEN_FP_16):Ditto;
> (TARGET_VECTOR_ELEN_32): Ditto;
> (TARGET_VECTOR_ELEN_64): Ditto;
> (TARGET_VECTOR_ELEN_FP_32):Ditto;
> (TARGET_VECTOR_ELEN_FP_64):Ditto;
> (TARGET_VECTOR_ELEN_FP_16):Ditto;
>  (MASK_ZVBB):   Ditto;
> (MASK_ZVBC):   Ditto;
> (TARGET_ZVBB): Ditto;
> (TARGET_ZVBC): Ditto;
> (MASK_ZVKG):   Ditto;
> (MASK_ZVKNED): Ditto;
> (MASK_ZVKNHA): Ditto;
> (MASK_ZVKNHB): Ditto;
> (MASK_ZVKSED): Ditto;
> (MASK_ZVKSH):  Ditto;
> (MASK_ZVKN):   Ditto;
> (MASK_ZVKNC):  Ditto;
> (MASK_ZVKNG):  Ditto;
> (MASK_ZVKS):   Ditto;
> (MASK_ZVKSC):  Ditto;
> (MASK_ZVKSG):  Ditto;
> (MASK_ZVKT):   Ditto;
> (TARGET_ZVKG): Ditto;
> (TARGET_ZVKNED):   Ditto;
> (TARGET_ZVKNHA):   Ditto;
> (TARGET_ZVKNHB):   Ditto;
> (TARGET_ZVKSED):   Ditto;
> (TARGET_ZVKSH):Ditto;
> (TARGET_ZVKN): Ditto;
> (TARGET_ZVKNC):Ditto;
> (TARGET_ZVKNG):Ditto;
> (TARGET_ZVKS): Ditto;
> (TARGET_ZVKSC):Ditto;
> (TARGET_ZVKSG):Ditto;
> (TARGET_ZVKT): Ditto;
> (MASK_ZVL32B): Ditto;
> (MASK_ZVL64B): Ditto;
> (MASK_ZVL128B):Ditto;
> (MASK_ZVL256B):Ditto;
> (MASK_ZVL512B):Ditto;
> (MASK_ZVL1024B):   Ditto;
> (MASK_ZVL2048B):   Ditto;
> (MASK_ZVL4096B):   Ditto;
> (MASK_ZVL8192B):   Ditto;
> (MASK_ZVL16384B):  Ditto;
> (MASK_ZVL32768B):  Ditto;
> (MASK_ZVL65536B):  Ditto;
> (TARGET_ZVL32B):   Ditto;
> (TARGET_ZVL64B):   Ditto;
> (TARGET_ZVL128B):  Ditto;
> (TARGET_ZVL256B):  Ditto;
> (TARGET_ZVL512B):  Ditto;
> (TARGET_ZVL1024B): Ditto;
> (TARGET_ZVL2048B): Ditto;
> (TARGET_ZVL4096B): Ditto;
> (TARGET_ZVL8192B): Ditto;
> (TARGET_ZVL16384B):Ditto;
> (TARGET_ZVL32768B):Ditto;
> (TARGET_ZVL65536B):Ditto;
> 

Re: [PATCH 3/5] RISC-V: Add Types to Un-Typed Zicond Instructions

2023-09-06 Thread Tsukasa OI via Gcc-patches
On 2023/09/07 2:50, Edwin Lu wrote:
> This patch creates a new "zicond" type and updates all zicond instructions
> with that type.
> 
> gcc/ChangeLog:
> 
>   * config/riscv/riscv.md: Add "zicond" type
>   * config/riscv/zicond.md: Update types
> 
> Signed-off-by: Edwin Lu 
> ---
>  gcc/config/riscv/riscv.md  | 5 +++--
>  gcc/config/riscv/zicond.md | 8 
>  2 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
> index 6684ad89cff..c329f55db43 100644
> --- a/gcc/config/riscv/riscv.md
> +++ b/gcc/config/riscv/riscv.md
> @@ -313,6 +313,7 @@ (define_attr "ext_enabled" "no,yes"
>  ;; cbocache block instructions
>  ;; crypto cryptography instructions
>  ;; csrcode size reduction instructions
> +;; zicondzicond instructions
>  ;; Classification of RVV instructions which will be added to each RVV .md 
> pattern and used by scheduler.
>  ;; rdvlenb vector byte length vlenb csrr read
>  ;; rdvlvector length vl csrr read
> @@ -422,8 +423,8 @@ (define_attr "type"
> mtc,mfc,const,arith,logical,shift,slt,imul,idiv,move,fmove,fadd,fmul,
> fmadd,fdiv,fcmp,fcvt,fsqrt,multi,auipc,sfb_alu,nop,trap,ghost,bitmanip,
> rotate,clmul,min,max,minu,maxu,clz,ctz,cpop,
> -   atomic,condmove,cbo,crypto,csr,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm,vsetvl,
> -   vlde,vste,vldm,vstm,vlds,vsts,
> +   atomic,condmove,cbo,crypto,csr,zicond,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm,
> +   vsetvl, vlde,vste,vldm,vstm,vlds,vsts,
> vldux,vldox,vstux,vstox,vldff,vldr,vstr,
> 
> vlsegde,vssegte,vlsegds,vssegts,vlsegdux,vlsegdox,vssegtux,vssegtox,vlsegdff,
> vialu,viwalu,vext,vicalu,vshift,vnshift,vicmp,viminmax,
> diff --git a/gcc/config/riscv/zicond.md b/gcc/config/riscv/zicond.md
> index 1721e1011ea..0269bd14399 100644
> --- a/gcc/config/riscv/zicond.md
> +++ b/gcc/config/riscv/zicond.md
> @@ -30,7 +30,7 @@ (define_insn "*czero.."
>(const_int 0)))]
>"TARGET_ZICOND"
>"czero.\t%0,%2,%1"
> -)
> +[(set_attr "type" "zicond")])
>  
>  (define_insn "*czero.."
>[(set (match_operand:GPR 0 "register_operand" "=r")
> @@ -40,7 +40,7 @@ (define_insn "*czero.."
>(match_operand:GPR 2 "register_operand"   "r")))]
>"TARGET_ZICOND"
>"czero.\t%0,%2,%1"
> -)
> +[(set_attr "type" "zicond")])
>  
>  ;; Special optimization under eq/ne in primitive semantics
>  (define_insn "*czero.eqz..opt1"
> @@ -51,7 +51,7 @@ (define_insn "*czero.eqz..opt1"
>(match_operand:GPR 3 "register_operand" "r")))]
>"TARGET_ZICOND && rtx_equal_p (operands[1], operands[2])"
>"czero.eqz\t%0,%3,%1"
> -)
> +[(set_attr "type" "zicond")])
>  
>  (define_insn "*czero.nez..opt2"
>[(set (match_operand:GPR 0 "register_operand"   "=r")
> @@ -61,7 +61,7 @@ (define_insn "*czero.nez..opt2"
>(match_operand:GPR 3 "register_operand" "1")))]
>"TARGET_ZICOND && rtx_equal_p (operands[1], operands[3])"
>"czero.eqz\t%0,%2,%1"
> -)
> +[(set_attr "type" "zicond")])
>  
>  ;; Combine creates this form in some cases (particularly the coremark
>  ;; CRC loop.

Looks okay to me but will need to resolve merge conflicts after commit
af88776caa20 ("RISC-V: Add support for 'XVentanaCondOps' reusing
'Zicond' support").

Thanks,
Tsukasa


Re: [RFC] libstdc++: Make --enable-libstdcxx-backtrace=auto default to yes

2023-09-06 Thread Hans-Peter Nilsson via Gcc-patches
> Date: Thu, 7 Sep 2023 00:11:04 +0100
> From: Jonathan Wakely via Gcc-patches 

> On Thu, 7 Sept 2023 at 00:10, Jonathan Wakely  wrote:
> > I don't think there's a bug. $is_hosted is true for
> > --enable-hosted-libstdcxx which is on by default.
> 
> And IIRC __STDC_HOSTED__ is defined unless you compile with -ffreestanding.

Also documented and thus fine by any (reasonable)
definition :) no need for anyone (me) to guess.

brgds, H-P


Re: [PATCH 2/5] RISC-V: Add Types for Un-Typed zc Instructions

2023-09-06 Thread Kito Cheng via Gcc-patches
csr is kind of confusing, I would suggest something like `pushpop` and
`mvpair`.

Edwin Lu  於 2023年9月7日 週四 01:51 寫道:

> This patch adds types to the untyped zc instructions. Creates a new
> type "csr" for these instructions for now.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.md: Add "csr" type
> * config/riscv/zc.md: Update types
>
> Signed-off-by: Edwin Lu 
> ---
>  gcc/config/riscv/riscv.md |   3 +-
>  gcc/config/riscv/zc.md| 102 +++---
>  2 files changed, 54 insertions(+), 51 deletions(-)
>
> diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
> index d80b6938f84..6684ad89cff 100644
> --- a/gcc/config/riscv/riscv.md
> +++ b/gcc/config/riscv/riscv.md
> @@ -312,6 +312,7 @@ (define_attr "ext_enabled" "no,yes"
>  ;; condmoveconditional moves
>  ;; cbocache block instructions
>  ;; crypto cryptography instructions
> +;; csrcode size reduction instructions
>  ;; Classification of RVV instructions which will be added to each RVV .md
> pattern and used by scheduler.
>  ;; rdvlenb vector byte length vlenb csrr read
>  ;; rdvlvector length vl csrr read
> @@ -421,7 +422,7 @@ (define_attr "type"
> mtc,mfc,const,arith,logical,shift,slt,imul,idiv,move,fmove,fadd,fmul,
> fmadd,fdiv,fcmp,fcvt,fsqrt,multi,auipc,sfb_alu,nop,trap,ghost,bitmanip,
> rotate,clmul,min,max,minu,maxu,clz,ctz,cpop,
> -   atomic,condmove,cbo,crypto,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm,vsetvl,
> +   atomic,condmove,cbo,crypto,csr,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm,vsetvl,
> vlde,vste,vldm,vstm,vlds,vsts,
> vldux,vldox,vstux,vstox,vldff,vldr,vstr,
>
> vlsegde,vssegte,vlsegds,vssegts,vlsegdux,vlsegdox,vssegtux,vssegtox,vlsegdff,
> diff --git a/gcc/config/riscv/zc.md b/gcc/config/riscv/zc.md
> index 77b28adde95..86f1afd66cb 100644
> --- a/gcc/config/riscv/zc.md
> +++ b/gcc/config/riscv/zc.md
> @@ -27,7 +27,7 @@ (define_insn "@gpr_multi_pop_up_to_ra_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop  {ra}, %0"
> -)
> +[(set_attr "type" "csr")])
>
>  (define_insn "@gpr_multi_pop_up_to_s0_"
>[(set (reg:X SP_REGNUM)
> @@ -41,7 +41,7 @@ (define_insn "@gpr_multi_pop_up_to_s0_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop  {ra, s0}, %0"
> -)
> +[(set_attr "type" "csr")])
>
>  (define_insn "@gpr_multi_pop_up_to_s1_"
>[(set (reg:X SP_REGNUM)
> @@ -58,7 +58,7 @@ (define_insn "@gpr_multi_pop_up_to_s1_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop  {ra, s0-s1}, %0"
> -)
> +[(set_attr "type" "csr")])
>
>  (define_insn "@gpr_multi_pop_up_to_s2_"
>[(set (reg:X SP_REGNUM)
> @@ -78,7 +78,7 @@ (define_insn "@gpr_multi_pop_up_to_s2_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop  {ra, s0-s2}, %0"
> -)
> +[(set_attr "type" "csr")])
>
>  (define_insn "@gpr_multi_pop_up_to_s3_"
>[(set (reg:X SP_REGNUM)
> @@ -101,7 +101,7 @@ (define_insn "@gpr_multi_pop_up_to_s3_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop  {ra, s0-s3}, %0"
> -)
> +[(set_attr "type" "csr")])
>
>  (define_insn "@gpr_multi_pop_up_to_s4_"
>[(set (reg:X SP_REGNUM)
> @@ -127,7 +127,7 @@ (define_insn "@gpr_multi_pop_up_to_s4_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop  {ra, s0-s4}, %0"
> -)
> +[(set_attr "type" "csr")])
>
>  (define_insn "@gpr_multi_pop_up_to_s5_"
>[(set (reg:X SP_REGNUM)
> @@ -156,7 +156,7 @@ (define_insn "@gpr_multi_pop_up_to_s5_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop  {ra, s0-s5}, %0"
> -)
> +[(set_attr "type" "csr")])
>
>  (define_insn "@gpr_multi_pop_up_to_s6_"
>[(set (reg:X SP_REGNUM)
> @@ -188,7 +188,7 @@ (define_insn "@gpr_multi_pop_up_to_s6_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop  {ra, s0-s6}, %0"
> -)
> +[(set_attr "type" "csr")])
>
>  (define_insn "@gpr_multi_pop_up_to_s7_"
>[(set (reg:X SP_REGNUM)
> @@ -223,7 +223,7 @@ (define_insn "@gpr_multi_pop_up_to_s7_"
>(const_int ]
>"TARGET_ZCMP"
>"cm.pop  {ra, s0-s7}, %0"
> -)
> +[(set_attr "type" "csr")])
>
>  (define_insn "@gpr_multi_pop_up_to_s8_"
>[(set (reg:X SP_REGNUM)
> @@ -261,7 +261,7 @@ (define_insn "@gpr_multi_pop_up_to_s8_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop  {ra, s0-s8}, %0"
> -)
> +[(set_attr "type" "csr")])
>
>  (define_insn "@gpr_multi_pop_up_to_s9_"
>[(set (reg:X SP_REGNUM)
> @@ -302,7 +302,7 @@ (define_insn "@gpr_multi_pop_up_to_s9_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop  {ra, s0-s9}, %0"
> -)
> +[(set_attr "type" "csr")])
>
>  (define_insn "@gpr_multi_pop_up_to_s11_"
>[(set (reg:X SP_REGNUM)
> @@ -349,7 +349,7 @@ (define_insn "@gpr_multi_pop_up_to_s11_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop  {ra, s0-s11}, %0"
> -)
> +[(set_attr "type" 

Re: [PATCH 1/5] RISC-V: Update Types for Vector Instructions

2023-09-06 Thread Kito Cheng via Gcc-patches
LGTM

Edwin Lu  於 2023年9月7日 週四 01:51 寫道:

> This patch adds types to vector instructions that were added after or were
> missed by the original patch
> https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628594.html
>
> gcc/ChangeLog:
>
> * config/riscv/autovec-opt.md: Update types
> * config/riscv/autovec.md: likewise
>
> Signed-off-by: Edwin Lu 
> ---
>  gcc/config/riscv/autovec-opt.md | 42 ++---
>  gcc/config/riscv/autovec.md | 28 +++---
>  2 files changed, 47 insertions(+), 23 deletions(-)
>
> diff --git a/gcc/config/riscv/autovec-opt.md
> b/gcc/config/riscv/autovec-opt.md
> index 1ca5ce97193..6cc1a01629c 100644
> --- a/gcc/config/riscv/autovec-opt.md
> +++ b/gcc/config/riscv/autovec-opt.md
> @@ -728,7 +728,8 @@ (define_insn_and_split "*cond_abs"
>  gen_int_mode (GET_MODE_NUNITS
> (mode), Pmode),
>  const0_rtx));
>DONE;
> -})
> +}
> +[(set_attr "type" "vector")])
>
>  ;; Combine vlmax neg and UNSPEC_VCOPYSIGN
>  (define_insn_and_split "*copysign_neg"
> @@ -746,7 +747,8 @@ (define_insn_and_split "*copysign_neg"
>riscv_vector::emit_vlmax_insn (code_for_pred_ncopysign (mode),
>riscv_vector::BINARY_OP, operands);
>DONE;
> -})
> +}
> +[(set_attr "type" "vector")])
>
>  ;; Combine sign_extend/zero_extend(vf2) and vcond_mask
>  (define_insn_and_split "*cond_"
> @@ -765,7 +767,8 @@ (define_insn_and_split
> "*cond_"
> gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
>riscv_vector::expand_cond_len_unop (icode, ops);
>DONE;
> -})
> +}
> +[(set_attr "type" "vector")])
>
>  ;; Combine sign_extend/zero_extend(vf4) and vcond_mask
>  (define_insn_and_split "*cond_"
> @@ -784,7 +787,8 @@ (define_insn_and_split
> "*cond_"
> gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
>riscv_vector::expand_cond_len_unop (icode, ops);
>DONE;
> -})
> +}
> +[(set_attr "type" "vector")])
>
>  ;; Combine sign_extend/zero_extend(vf8) and vcond_mask
>  (define_insn_and_split "*cond_"
> @@ -803,7 +807,8 @@ (define_insn_and_split
> "*cond_"
> gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
>riscv_vector::expand_cond_len_unop (icode, ops);
>DONE;
> -})
> +}
> +[(set_attr "type" "vector")])
>
>  ;; Combine trunc(vf2) + vcond_mask
>  (define_insn_and_split "*cond_trunc"
> @@ -823,7 +828,8 @@ (define_insn_and_split
> "*cond_trunc"
> gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
>riscv_vector::expand_cond_len_unop (icode, ops);
>DONE;
> -})
> +}
> +[(set_attr "type" "vector")])
>
>  ;; Combine FP sign_extend/zero_extend(vf2) and vcond_mask
>  (define_insn_and_split "*cond_extend"
> @@ -842,7 +848,8 @@ (define_insn_and_split
> "*cond_extend"
> gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
>riscv_vector::expand_cond_len_unop (icode, ops);
>DONE;
> -})
> +}
> +[(set_attr "type" "vector")])
>
>  ;; Combine FP trunc(vf2) + vcond_mask
>  (define_insn_and_split "*cond_trunc"
> @@ -862,7 +869,8 @@ (define_insn_and_split
> "*cond_trunc"
> gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
>riscv_vector::expand_cond_len_unop (icode, ops);
>DONE;
> -})
> +}
> +[(set_attr "type" "vector")])
>
>  ;; Combine convert(FP->INT) + vcond_mask
>  (define_insn_and_split "*cond_"
> @@ -882,7 +890,8 @@ (define_insn_and_split "*cond_"
> gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
>riscv_vector::expand_cond_len_unop (icode, ops);
>DONE;
> -})
> +}
> +[(set_attr "type" "vector")])
>
>  ;; Combine convert(INT->FP) + vcond_mask
>  (define_insn_and_split "*cond_"
> @@ -902,7 +911,8 @@ (define_insn_and_split
> "*cond_"
> gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
>riscv_vector::expand_cond_len_unop (icode, ops);
>DONE;
> -})
> +}
> +[(set_attr "type" "vector")])
>
>  ;; Combine convert(FP->2xINT) + vcond_mask
>  (define_insn_and_split "*cond_"
> @@ -922,7 +932,8 @@ (define_insn_and_split "*cond_"
> gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
>riscv_vector::expand_cond_len_unop (icode, ops);
>DONE;
> -})
> +}
> +[(set_attr "type" "vector")])
>
>  ;; Combine convert(INT->2xFP) + vcond_mask
>  (define_insn_and_split "*cond_"
> @@ -942,7 +953,8 @@ (define_insn_and_split
> "*cond_"
> gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
>riscv_vector::expand_cond_len_unop (icode, ops);
>DONE;
> -})
> +}
> +[(set_attr "type" "vector")])
>
>  ;; Combine convert(2xFP->INT) + vcond_mask
>  (define_insn_and_split "*cond_"
> @@ -962,7 +974,8 @@ (define_insn_and_split "*cond_"
> gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
>riscv_vector::expand_cond_len_unop (icode, ops);
>DONE;
> -})
> +}
> +[(set_attr "type" "vector")])
>
>  ;; Combine convert(2xINT->FP) + vcond_mask
>  (define_insn_and_split "*cond_2"
> @@ -982,4 +995,5 @@ 

Re: [PATCH 4/5] RISC-V: Update Types for RISC-V Instructions

2023-09-06 Thread Kito Cheng via Gcc-patches
LGTM

Edwin Lu  於 2023年9月7日 週四 01:52 寫道:

> This patch adds types to riscv instructions that were added or were
> missed by the original patch
> https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628996.html
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.md: Update types
>
> Signed-off-by: Edwin Lu 
> ---
>  gcc/config/riscv/riscv.md | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
> index c329f55db43..c1cecd27815 100644
> --- a/gcc/config/riscv/riscv.md
> +++ b/gcc/config/riscv/riscv.md
> @@ -2223,6 +2223,7 @@ (define_insn "movsidf2_low_rv32"
>"TARGET_HARD_FLOAT && !TARGET_64BIT && TARGET_ZFA"
>"fmv.x.w\t%0,%1"
>[(set_attr "move_type" "fmove")
> +   (set_attr "type" "fmove")
> (set_attr "mode" "DF")])
>
>
> @@ -2235,6 +2236,7 @@ (define_insn "movsidf2_high_rv32"
>"TARGET_HARD_FLOAT && !TARGET_64BIT && TARGET_ZFA"
>"fmvh.x.d\t%0,%1"
>[(set_attr "move_type" "fmove")
> +   (set_attr "type" "fmove")
> (set_attr "mode" "DF")])
>
>  (define_insn "movdfsisi3_rv32"
> @@ -2247,6 +2249,7 @@ (define_insn "movdfsisi3_rv32"
>"TARGET_HARD_FLOAT && !TARGET_64BIT && TARGET_ZFA"
>"fmvp.d.x\t%0,%2,%1"
>[(set_attr "move_type" "fmove")
> +   (set_attr "type" "fmove")
> (set_attr "mode" "DF")])
>
>  (define_split
> --
> 2.34.1
>
>


Re: [PATCH 3/5] RISC-V: Add Types to Un-Typed Zicond Instructions

2023-09-06 Thread Kito Cheng via Gcc-patches
LGTM

Edwin Lu  於 2023年9月7日 週四 01:53 寫道:

> This patch creates a new "zicond" type and updates all zicond instructions
> with that type.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.md: Add "zicond" type
> * config/riscv/zicond.md: Update types
>
> Signed-off-by: Edwin Lu 
> ---
>  gcc/config/riscv/riscv.md  | 5 +++--
>  gcc/config/riscv/zicond.md | 8 
>  2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
> index 6684ad89cff..c329f55db43 100644
> --- a/gcc/config/riscv/riscv.md
> +++ b/gcc/config/riscv/riscv.md
> @@ -313,6 +313,7 @@ (define_attr "ext_enabled" "no,yes"
>  ;; cbocache block instructions
>  ;; crypto cryptography instructions
>  ;; csrcode size reduction instructions
> +;; zicondzicond instructions
>  ;; Classification of RVV instructions which will be added to each RVV .md
> pattern and used by scheduler.
>  ;; rdvlenb vector byte length vlenb csrr read
>  ;; rdvlvector length vl csrr read
> @@ -422,8 +423,8 @@ (define_attr "type"
> mtc,mfc,const,arith,logical,shift,slt,imul,idiv,move,fmove,fadd,fmul,
> fmadd,fdiv,fcmp,fcvt,fsqrt,multi,auipc,sfb_alu,nop,trap,ghost,bitmanip,
> rotate,clmul,min,max,minu,maxu,clz,ctz,cpop,
> -   atomic,condmove,cbo,crypto,csr,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm,vsetvl,
> -   vlde,vste,vldm,vstm,vlds,vsts,
> +   atomic,condmove,cbo,crypto,csr,zicond,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm,
> +   vsetvl, vlde,vste,vldm,vstm,vlds,vsts,
> vldux,vldox,vstux,vstox,vldff,vldr,vstr,
>
> vlsegde,vssegte,vlsegds,vssegts,vlsegdux,vlsegdox,vssegtux,vssegtox,vlsegdff,
> vialu,viwalu,vext,vicalu,vshift,vnshift,vicmp,viminmax,
> diff --git a/gcc/config/riscv/zicond.md b/gcc/config/riscv/zicond.md
> index 1721e1011ea..0269bd14399 100644
> --- a/gcc/config/riscv/zicond.md
> +++ b/gcc/config/riscv/zicond.md
> @@ -30,7 +30,7 @@ (define_insn "*czero.."
>(const_int 0)))]
>"TARGET_ZICOND"
>"czero.\t%0,%2,%1"
> -)
> +[(set_attr "type" "zicond")])
>
>  (define_insn "*czero.."
>[(set (match_operand:GPR 0 "register_operand" "=r")
> @@ -40,7 +40,7 @@ (define_insn "*czero.."
>(match_operand:GPR 2 "register_operand"
>  "r")))]
>"TARGET_ZICOND"
>"czero.\t%0,%2,%1"
> -)
> +[(set_attr "type" "zicond")])
>
>  ;; Special optimization under eq/ne in primitive semantics
>  (define_insn "*czero.eqz..opt1"
> @@ -51,7 +51,7 @@ (define_insn "*czero.eqz..opt1"
>(match_operand:GPR 3 "register_operand" "r")))]
>"TARGET_ZICOND && rtx_equal_p (operands[1], operands[2])"
>"czero.eqz\t%0,%3,%1"
> -)
> +[(set_attr "type" "zicond")])
>
>  (define_insn "*czero.nez..opt2"
>[(set (match_operand:GPR 0 "register_operand"   "=r")
> @@ -61,7 +61,7 @@ (define_insn "*czero.nez..opt2"
>(match_operand:GPR 3 "register_operand" "1")))]
>"TARGET_ZICOND && rtx_equal_p (operands[1], operands[3])"
>"czero.eqz\t%0,%2,%1"
> -)
> +[(set_attr "type" "zicond")])
>
>  ;; Combine creates this form in some cases (particularly the coremark
>  ;; CRC loop.
> --
> 2.34.1
>
>


Re: [RFC] libstdc++: Make --enable-libstdcxx-backtrace=auto default to yes

2023-09-06 Thread Jonathan Wakely via Gcc-patches
On Thu, 7 Sept 2023 at 00:10, Jonathan Wakely  wrote:
>
> On Thu, 7 Sept 2023 at 00:09, Hans-Peter Nilsson  wrote:
> >
> > > From: Jonathan Wakely 
> > > Date: Wed, 6 Sep 2023 23:30:08 +0100
> >
> > > On Mon, 4 Sept 2023 at 17:49, Jonathan Wakely  
> > > wrote:
> > > >
> > > > On Mon, 4 Sept 2023 at 17:47, Hans-Peter Nilsson via Libstdc++
> > > >  wrote:
> > > > >
> > > > > > Date: Fri, 1 Sep 2023 12:16:40 +0100
> > > > > > Reply-To: Jonathan Wakely 
> > > > > >
> > > > > > On Wed, 23 Aug 2023 at 17:03, Jonathan Wakely via Libstdc++
> > > > > >  wrote:
> > > > > > >
> > > > > > > Any objections to this? It's a C++23 feture, so should be enabled 
> > > > > > > by
> > > > > > > default.
> > > > > >
> > > > > > I've pushed this to trunk, so let's see what breaks!
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > -- >8 --
> > > > > > >
> > > > > > > This causes libstdc++_libbacktrace.a to be built by default. This 
> > > > > > > might
> > > > > > > fail on some targets, in which case we can make the 'auto' choice 
> > > > > > > expand
> > > > > > > to either 'yes' or 'no' depending on the target.
> > > > > > >
> > > > > > > libstdc++-v3/ChangeLog:
> > > > > > >
> > > > > > > * acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Default to yes.
> > > > > > > * configure: Regenerate.
> > > > >
> > > > > Incidentally, should check_effective_target_stacktrace in
> > > > > libstdc++.exp also be adjusted to match; removing the
> > > > > _GLIBCXX_HOSTED condition?
> > > >
> > > > No, it should still depend on is_hosted. The acinclude.m4 macro should
> > > > check that.
> > >
> > > Done in r14-3761-g6de5f5a4fe85bd
> >
> > Aha, that's what you meant.  I thought you meant that just
> > check_effective_target_stacktrace should be gated on
> > $is_hosted.
> >
> > Yeah, it makes sense not to have backtrace enabled by
> > default for ! $is_hosted.  On the other hand, bare-iron
> > targets like cris-elf apparently *are* hosted, according to
> > "#if __STDC_HOSTED__".  I guess I'll have to dig into what
> > the definition of "hosted" is, because I don't agree by the
> > layman obvious definition.  Maybe there's a bug to fix.
>
> I don't think there's a bug. $is_hosted is true for
> --enable-hosted-libstdcxx which is on by default.

And IIRC __STDC_HOSTED__ is defined unless you compile with -ffreestanding.


>
> > There sure are many yaks to shave these days.
> >
> > brgds, H-P
> >



Re: [RFC] libstdc++: Make --enable-libstdcxx-backtrace=auto default to yes

2023-09-06 Thread Jonathan Wakely via Gcc-patches
On Thu, 7 Sept 2023 at 00:09, Hans-Peter Nilsson  wrote:
>
> > From: Jonathan Wakely 
> > Date: Wed, 6 Sep 2023 23:30:08 +0100
>
> > On Mon, 4 Sept 2023 at 17:49, Jonathan Wakely  wrote:
> > >
> > > On Mon, 4 Sept 2023 at 17:47, Hans-Peter Nilsson via Libstdc++
> > >  wrote:
> > > >
> > > > > Date: Fri, 1 Sep 2023 12:16:40 +0100
> > > > > Reply-To: Jonathan Wakely 
> > > > >
> > > > > On Wed, 23 Aug 2023 at 17:03, Jonathan Wakely via Libstdc++
> > > > >  wrote:
> > > > > >
> > > > > > Any objections to this? It's a C++23 feture, so should be enabled by
> > > > > > default.
> > > > >
> > > > > I've pushed this to trunk, so let's see what breaks!
> > > > >
> > > > >
> > > > > >
> > > > > > -- >8 --
> > > > > >
> > > > > > This causes libstdc++_libbacktrace.a to be built by default. This 
> > > > > > might
> > > > > > fail on some targets, in which case we can make the 'auto' choice 
> > > > > > expand
> > > > > > to either 'yes' or 'no' depending on the target.
> > > > > >
> > > > > > libstdc++-v3/ChangeLog:
> > > > > >
> > > > > > * acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Default to yes.
> > > > > > * configure: Regenerate.
> > > >
> > > > Incidentally, should check_effective_target_stacktrace in
> > > > libstdc++.exp also be adjusted to match; removing the
> > > > _GLIBCXX_HOSTED condition?
> > >
> > > No, it should still depend on is_hosted. The acinclude.m4 macro should
> > > check that.
> >
> > Done in r14-3761-g6de5f5a4fe85bd
>
> Aha, that's what you meant.  I thought you meant that just
> check_effective_target_stacktrace should be gated on
> $is_hosted.
>
> Yeah, it makes sense not to have backtrace enabled by
> default for ! $is_hosted.  On the other hand, bare-iron
> targets like cris-elf apparently *are* hosted, according to
> "#if __STDC_HOSTED__".  I guess I'll have to dig into what
> the definition of "hosted" is, because I don't agree by the
> layman obvious definition.  Maybe there's a bug to fix.

I don't think there's a bug. $is_hosted is true for
--enable-hosted-libstdcxx which is on by default.


> There sure are many yaks to shave these days.
>
> brgds, H-P
>



Re: [RFC] libstdc++: Make --enable-libstdcxx-backtrace=auto default to yes

2023-09-06 Thread Hans-Peter Nilsson via Gcc-patches
> From: Jonathan Wakely 
> Date: Wed, 6 Sep 2023 23:30:08 +0100

> On Mon, 4 Sept 2023 at 17:49, Jonathan Wakely  wrote:
> >
> > On Mon, 4 Sept 2023 at 17:47, Hans-Peter Nilsson via Libstdc++
> >  wrote:
> > >
> > > > Date: Fri, 1 Sep 2023 12:16:40 +0100
> > > > Reply-To: Jonathan Wakely 
> > > >
> > > > On Wed, 23 Aug 2023 at 17:03, Jonathan Wakely via Libstdc++
> > > >  wrote:
> > > > >
> > > > > Any objections to this? It's a C++23 feture, so should be enabled by
> > > > > default.
> > > >
> > > > I've pushed this to trunk, so let's see what breaks!
> > > >
> > > >
> > > > >
> > > > > -- >8 --
> > > > >
> > > > > This causes libstdc++_libbacktrace.a to be built by default. This 
> > > > > might
> > > > > fail on some targets, in which case we can make the 'auto' choice 
> > > > > expand
> > > > > to either 'yes' or 'no' depending on the target.
> > > > >
> > > > > libstdc++-v3/ChangeLog:
> > > > >
> > > > > * acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Default to yes.
> > > > > * configure: Regenerate.
> > >
> > > Incidentally, should check_effective_target_stacktrace in
> > > libstdc++.exp also be adjusted to match; removing the
> > > _GLIBCXX_HOSTED condition?
> >
> > No, it should still depend on is_hosted. The acinclude.m4 macro should
> > check that.
> 
> Done in r14-3761-g6de5f5a4fe85bd

Aha, that's what you meant.  I thought you meant that just
check_effective_target_stacktrace should be gated on
$is_hosted.

Yeah, it makes sense not to have backtrace enabled by
default for ! $is_hosted.  On the other hand, bare-iron
targets like cris-elf apparently *are* hosted, according to
"#if __STDC_HOSTED__".  I guess I'll have to dig into what
the definition of "hosted" is, because I don't agree by the
layman obvious definition.  Maybe there's a bug to fix.
There sure are many yaks to shave these days.

brgds, H-P


godump.cc patch committed: Handle _BitInt

2023-09-06 Thread Ian Lance Taylor via Gcc-patches
This patch to godump.cc adds support for BITINT_TYPE.  Bootstrapped
and ran godump and Go tests on x86_64-pc-linux-gnu.  Committed to
mainline.

Ian

gcc/
PR go/111310
* godump.cc (go_format_type): Handle BITINT_TYPE.

gcc/testsuite/
PR go/111310
   * gcc.misc-tests/godump-1.c: Add _BitInt test cases.
diff --git a/gcc/godump.cc b/gcc/godump.cc
index 0893d5fbc97..bdd2d108d76 100644
--- a/gcc/godump.cc
+++ b/gcc/godump.cc
@@ -760,6 +760,25 @@ go_format_type (class godump_container *container, tree 
type,
   }
   break;
 
+case BITINT_TYPE:
+  {
+   const char *s;
+   char buf[100];
+
+   s = go_get_uinttype_for_precision (TYPE_PRECISION (type),
+  TYPE_UNSIGNED (type));
+   if (s == NULL)
+ {
+   snprintf (buf, sizeof buf, "INVALID-bitint-%u%s",
+ TYPE_PRECISION (type),
+ TYPE_UNSIGNED (type) ? "u" : "");
+   s = buf;
+   ret = false;
+ }
+   obstack_grow (ob, s, strlen(s));
+  }
+  break;
+
 case REAL_TYPE:
   {
const char *s;
diff --git a/gcc/testsuite/gcc.misc-tests/godump-1.c 
b/gcc/testsuite/gcc.misc-tests/godump-1.c
index 95dabdc0e4c..f359a657827 100644
--- a/gcc/testsuite/gcc.misc-tests/godump-1.c
+++ b/gcc/testsuite/gcc.misc-tests/godump-1.c
@@ -234,6 +234,17 @@ const char cc_v1;
 cc_t cc_v2;
 /* { dg-final { scan-file godump-1.out "(?n)^var _cc_v2 _cc_t$" } } */
 
+_BitInt(32) b32_v;
+/* { dg-final { scan-file godump-1.out "(?n)^var _b32_v int32$" } } */
+
+_BitInt(64) b64_v;
+/* { dg-final { scan-file godump-1.out "(?n)^var _b64_v int64$" } } */
+
+unsigned _BitInt(32) b32u_v;
+/* { dg-final { scan-file godump-1.out "(?n)^var _b32u_v uint32$" } } */
+
+_BitInt(33) b33_v;
+/* { dg-final { scan-file godump-1.out "(?n)^// var _b33_v INVALID-bitint-33$" 
} } */
 
 /*** pointer and array types ***/
 typedef void *vp_t;


Re: [RFC] libstdc++: Make --enable-libstdcxx-backtrace=auto default to yes

2023-09-06 Thread Jonathan Wakely via Gcc-patches
On Mon, 4 Sept 2023 at 17:49, Jonathan Wakely  wrote:
>
> On Mon, 4 Sept 2023 at 17:47, Hans-Peter Nilsson via Libstdc++
>  wrote:
> >
> > > Date: Fri, 1 Sep 2023 12:16:40 +0100
> > > Reply-To: Jonathan Wakely 
> > >
> > > On Wed, 23 Aug 2023 at 17:03, Jonathan Wakely via Libstdc++
> > >  wrote:
> > > >
> > > > Any objections to this? It's a C++23 feture, so should be enabled by
> > > > default.
> > >
> > > I've pushed this to trunk, so let's see what breaks!
> > >
> > >
> > > >
> > > > -- >8 --
> > > >
> > > > This causes libstdc++_libbacktrace.a to be built by default. This might
> > > > fail on some targets, in which case we can make the 'auto' choice expand
> > > > to either 'yes' or 'no' depending on the target.
> > > >
> > > > libstdc++-v3/ChangeLog:
> > > >
> > > > * acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Default to yes.
> > > > * configure: Regenerate.
> >
> > Incidentally, should check_effective_target_stacktrace in
> > libstdc++.exp also be adjusted to match; removing the
> > _GLIBCXX_HOSTED condition?
>
> No, it should still depend on is_hosted. The acinclude.m4 macro should
> check that.

Done in r14-3761-g6de5f5a4fe85bd



[committed] libstdc++: Disable support by default for freestanding

2023-09-06 Thread Jonathan Wakely via Gcc-patches
Tested x86_64-linux and x86_64-elf. Pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

* acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Disable by default
for freestanding.
* configure: Regenerate.
---
 libstdc++-v3/acinclude.m4 | 2 +-
 libstdc++-v3/configure| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 50c808c6b2d..b7210e09d89 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -5481,7 +5481,7 @@ BACKTRACE_CPPFLAGS="$BACKTRACE_CPPFLAGS 
-DBACKTRACE_ELF_SIZE=$elfsize"
 
   AC_MSG_CHECKING([whether to build libbacktrace support])
   if test "$enable_libstdcxx_backtrace" = "auto"; then
-enable_libstdcxx_backtrace=yes
+enable_libstdcxx_backtrace="$is_hosted"
   fi
   AC_MSG_RESULT($enable_libstdcxx_backtrace)
   if test "$enable_libstdcxx_backtrace" = "yes"; then
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index db1932300c0..dcb9fd6158c 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -73156,7 +73156,7 @@ BACKTRACE_CPPFLAGS="$BACKTRACE_CPPFLAGS 
-DBACKTRACE_ELF_SIZE=$elfsize"
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether to build 
libbacktrace support" >&5
 $as_echo_n "checking whether to build libbacktrace support... " >&6; }
   if test "$enable_libstdcxx_backtrace" = "auto"; then
-enable_libstdcxx_backtrace=yes
+enable_libstdcxx_backtrace="$is_hosted"
   fi
   { $as_echo "$as_me:${as_lineno-$LINENO}: result: 
$enable_libstdcxx_backtrace" >&5
 $as_echo "$enable_libstdcxx_backtrace" >&6; }
-- 
2.41.0



Re: [PATCH] c++: refine CWG 2369 satisfaction vs non-dep convs [PR99599]

2023-09-06 Thread Patrick Palka via Gcc-patches
On Mon, 28 Aug 2023, Jason Merrill wrote:

> On 8/24/23 09:31, Patrick Palka wrote:
> > On Wed, 23 Aug 2023, Jason Merrill wrote:
> > 
> > > On 8/21/23 21:51, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look like
> > > > a reasonable approach?  I didn't observe any compile time/memory impact
> > > > of this change.
> > > > 
> > > > -- >8 --
> > > > 
> > > > As described in detail in the PR, CWG 2369 has the surprising
> > > > consequence of introducing constraint recursion in seemingly valid and
> > > > innocent code.
> > > > 
> > > > This patch attempts to fix this surpising behavior for the majority
> > > > of problematic use cases.  Rather than checking satisfaction before
> > > > _all_ non-dependent conversions, as specified by the CWG issue,
> > > > this patch makes us first check "safe" non-dependent conversions,
> > > > then satisfaction, then followed by "unsafe" non-dependent conversions.
> > > > In this case, a conversion is "safe" if computing it is guaranteed
> > > > to not induce template instantiation.  This patch heuristically
> > > > determines "safety" by checking for a constructor template or conversion
> > > > function template in the (class) parm or arg types respectively.
> > > > If neither type has such a member, then computing the conversion
> > > > should not induce instantiation (modulo satisfaction checking of
> > > > non-template constructor and conversion functions I suppose).
> > > > 
> > > > + /* We're checking only non-instantiating conversions.
> > > > +A conversion may instantiate only if it's to/from a
> > > > +class type that has a constructor template/conversion
> > > > +function template.  */
> > > > + tree parm_nonref = non_reference (parm);
> > > > + tree type_nonref = non_reference (type);
> > > > +
> > > > + if (CLASS_TYPE_P (parm_nonref))
> > > > +   {
> > > > + if (!COMPLETE_TYPE_P (parm_nonref)
> > > > + && CLASSTYPE_TEMPLATE_INSTANTIATION (parm_nonref))
> > > > +   return unify_success (explain_p);
> > > > +
> > > > + tree ctors = get_class_binding (parm_nonref,
> > > > + complete_ctor_identifier);
> > > > + for (tree ctor : lkp_range (ctors))
> > > > +   if (TREE_CODE (ctor) == TEMPLATE_DECL)
> > > > + return unify_success (explain_p);
> > > 
> > > Today we discussed maybe checking CLASSTYPE_NON_AGGREGATE?
> > 
> > Done; all dups of this PR seem to use tag types that are aggregates, so this
> > seems like a good simplification.  I also made us punt if the arg type has a
> > constrained non-template conversion function.
> > 
> > > 
> > > Also, instantiation can also happen when checking for conversion to a
> > > pointer
> > > or reference to base class.
> > 
> > Oops, I suppose we just need to strip pointer types upfront as well.  The
> > !COMPLETE_TYPE_P && CLASSTYPE_TEMPLATE_INSTANTIATION tests will then make
> > sure we deem a potential derived-to-base conversion unsafe if appropriate
> > IIUC.
> > 
> > How does the following look?
> > 
> > -- >8 --
> > 
> > Subject: [PATCH] c++: refine CWG 2369 satisfaction vs non-dep convs
> > [PR99599]
> > 
> > PR c++/99599
> > 
> > gcc/cp/ChangeLog:
> > 
> > * config-lang.in (gtfiles): Add search.cc.
> > * pt.cc (check_non_deducible_conversions): Add bool parameter
> > passed down to check_non_deducible_conversion.
> > (fn_type_unification): Call check_non_deducible_conversions
> > an extra time before satisfaction with noninst_only_p=true.
> > (check_non_deducible_conversion): Add bool parameter controlling
> > whether to compute only conversions that are guaranteed to
> > not induce template instantiation.
> > * search.cc (conversions_cache): Define.
> > (lookup_conversions): Use it to cache the lookup.  Improve cache
> > rate by considering TYPE_MAIN_VARIANT of the type.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * g++.dg/cpp2a/concepts-nondep4.C: New test.
> > ---
> >   gcc/cp/config-lang.in |  1 +
> >   gcc/cp/pt.cc  | 81 +--
> >   gcc/cp/search.cc  | 14 +++-
> >   gcc/testsuite/g++.dg/cpp2a/concepts-nondep4.C | 21 +
> >   4 files changed, 110 insertions(+), 7 deletions(-)
> >   create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-nondep4.C
> > 
> > @@ -22921,6 +22933,65 @@ check_non_deducible_conversion (tree parm, tree
> > arg, unification_kind_t strict,
> >   {
> > bool ok = false;
> > tree conv_arg = TYPE_P (arg) ? NULL_TREE : arg;
> > +  if (conv_p && *conv_p)
> > +   {
> > + /* This conversion was already computed earlier (when
> > +computing only non-instantiating conversions).  */
> > + gcc_checking_assert (!noninst_only_p);
> > + return unify_success 

[PATCH] c++: cache conversion function lookup

2023-09-06 Thread Patrick Palka via Gcc-patches
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?  This cache apparently has a 98% hit rate for TYPE_HAS_CONVERSION
types on some test files.

-- >8 --

gcc/cp/ChangeLog:

* config-lang.in (gtfiles): Add search.cc.
* search.cc (lookup_conversions_cache): Define.
(lookup_conversions): Use it to cache he lookup.
Improve cache rate by considering TYPE_MAIN_VARIANT
of the type.
---
 gcc/cp/config-lang.in |  1 +
 gcc/cp/search.cc  | 11 +++
 2 files changed, 12 insertions(+)

diff --git a/gcc/cp/config-lang.in b/gcc/cp/config-lang.in
index a6c7883cc24..e34c392d208 100644
--- a/gcc/cp/config-lang.in
+++ b/gcc/cp/config-lang.in
@@ -52,6 +52,7 @@ gtfiles="\
 \$(srcdir)/cp/name-lookup.cc \
 \$(srcdir)/cp/parser.cc \$(srcdir)/cp/pt.cc \
 \$(srcdir)/cp/rtti.cc \
+\$(srcdir)/cp/search.cc \
 \$(srcdir)/cp/semantics.cc \
 \$(srcdir)/cp/tree.cc \$(srcdir)/cp/typeck2.cc \
 \$(srcdir)/cp/vtable-class-hierarchy.cc \
diff --git a/gcc/cp/search.cc b/gcc/cp/search.cc
index cd80f285ac9..d5a2c57f59c 100644
--- a/gcc/cp/search.cc
+++ b/gcc/cp/search.cc
@@ -2582,6 +2582,10 @@ lookup_conversions_r (tree binfo, int virtual_depth, int 
virtualness,
   return my_virtualness;
 }
 
+/* A cache of the result of lookup_conversions.  */
+
+static GTY((cache)) type_tree_cache_map *lookup_conversions_cache;
+
 /* Return a TREE_LIST containing all the non-hidden user-defined
conversion functions for TYPE (and its base-classes).  The
TREE_VALUE of each node is the FUNCTION_DECL of the conversion
@@ -2596,10 +2600,14 @@ lookup_conversions (tree type)
 {
   tree convs;
 
+  type = TYPE_MAIN_VARIANT (type);
   complete_type (type);
   if (!CLASS_TYPE_P (type) || !TYPE_BINFO (type))
 return NULL_TREE;
 
+  if (tree *c = hash_map_safe_get (lookup_conversions_cache, type))
+return *c;
+
   lookup_conversions_r (TYPE_BINFO (type), 0, 0, NULL_TREE, NULL_TREE, );
 
   tree list = NULL_TREE;
@@ -2618,6 +2626,7 @@ lookup_conversions (tree type)
}
 }
 
+  hash_map_safe_put (lookup_conversions_cache, type, list);
   return list;
 }
 
@@ -2798,3 +2807,5 @@ any_dependent_bases_p (tree type)
 
   return false;
 }
+
+#include "gt-cp-search.h"
-- 
2.42.0.122.g1fc548b2d6



Re: [PATCH] c++: refine CWG 2369 satisfaction vs non-dep convs [PR99599]

2023-09-06 Thread Patrick Palka via Gcc-patches



On Mon, 28 Aug 2023, Jason Merrill wrote:

> On 8/24/23 09:31, Patrick Palka wrote:
> > On Wed, 23 Aug 2023, Jason Merrill wrote:
> > 
> > > On 8/21/23 21:51, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look like
> > > > a reasonable approach?  I didn't observe any compile time/memory impact
> > > > of this change.
> > > > 
> > > > -- >8 --
> > > > 
> > > > As described in detail in the PR, CWG 2369 has the surprising
> > > > consequence of introducing constraint recursion in seemingly valid and
> > > > innocent code.
> > > > 
> > > > This patch attempts to fix this surpising behavior for the majority
> > > > of problematic use cases.  Rather than checking satisfaction before
> > > > _all_ non-dependent conversions, as specified by the CWG issue,
> > > > this patch makes us first check "safe" non-dependent conversions,
> > > > then satisfaction, then followed by "unsafe" non-dependent conversions.
> > > > In this case, a conversion is "safe" if computing it is guaranteed
> > > > to not induce template instantiation.  This patch heuristically
> > > > determines "safety" by checking for a constructor template or conversion
> > > > function template in the (class) parm or arg types respectively.
> > > > If neither type has such a member, then computing the conversion
> > > > should not induce instantiation (modulo satisfaction checking of
> > > > non-template constructor and conversion functions I suppose).
> > > > 
> > > > + /* We're checking only non-instantiating conversions.
> > > > +A conversion may instantiate only if it's to/from a
> > > > +class type that has a constructor template/conversion
> > > > +function template.  */
> > > > + tree parm_nonref = non_reference (parm);
> > > > + tree type_nonref = non_reference (type);
> > > > +
> > > > + if (CLASS_TYPE_P (parm_nonref))
> > > > +   {
> > > > + if (!COMPLETE_TYPE_P (parm_nonref)
> > > > + && CLASSTYPE_TEMPLATE_INSTANTIATION (parm_nonref))
> > > > +   return unify_success (explain_p);
> > > > +
> > > > + tree ctors = get_class_binding (parm_nonref,
> > > > + complete_ctor_identifier);
> > > > + for (tree ctor : lkp_range (ctors))
> > > > +   if (TREE_CODE (ctor) == TEMPLATE_DECL)
> > > > + return unify_success (explain_p);
> > > 
> > > Today we discussed maybe checking CLASSTYPE_NON_AGGREGATE?
> > 
> > Done; all dups of this PR seem to use tag types that are aggregates, so this
> > seems like a good simplification.  I also made us punt if the arg type has a
> > constrained non-template conversion function.
> > 
> > > 
> > > Also, instantiation can also happen when checking for conversion to a
> > > pointer
> > > or reference to base class.
> > 
> > Oops, I suppose we just need to strip pointer types upfront as well.  The
> > !COMPLETE_TYPE_P && CLASSTYPE_TEMPLATE_INSTANTIATION tests will then make
> > sure we deem a potential derived-to-base conversion unsafe if appropriate
> > IIUC.
> > 
> > How does the following look?
> > 
> > -- >8 --
> > 
> > Subject: [PATCH] c++: refine CWG 2369 satisfaction vs non-dep convs
> > [PR99599]
> > 
> > PR c++/99599
> > 
> > gcc/cp/ChangeLog:
> > 
> > * config-lang.in (gtfiles): Add search.cc.
> > * pt.cc (check_non_deducible_conversions): Add bool parameter
> > passed down to check_non_deducible_conversion.
> > (fn_type_unification): Call check_non_deducible_conversions
> > an extra time before satisfaction with noninst_only_p=true.
> > (check_non_deducible_conversion): Add bool parameter controlling
> > whether to compute only conversions that are guaranteed to
> > not induce template instantiation.
> > * search.cc (conversions_cache): Define.
> > (lookup_conversions): Use it to cache the lookup.  Improve cache
> > rate by considering TYPE_MAIN_VARIANT of the type.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * g++.dg/cpp2a/concepts-nondep4.C: New test.
> > ---
> >   gcc/cp/config-lang.in |  1 +
> >   gcc/cp/pt.cc  | 81 +--
> >   gcc/cp/search.cc  | 14 +++-
> >   gcc/testsuite/g++.dg/cpp2a/concepts-nondep4.C | 21 +
> >   4 files changed, 110 insertions(+), 7 deletions(-)
> >   create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-nondep4.C
> > 
> > @@ -22921,6 +22933,65 @@ check_non_deducible_conversion (tree parm, tree
> > arg, unification_kind_t strict,
> >   {
> > bool ok = false;
> > tree conv_arg = TYPE_P (arg) ? NULL_TREE : arg;
> > +  if (conv_p && *conv_p)
> > +   {
> > + /* This conversion was already computed earlier (when
> > +computing only non-instantiating conversions).  */
> > + gcc_checking_assert (!noninst_only_p);
> > + return unify_success 

Re: [C PATCH 1/6] c: reorganize recursive type checking

2023-09-06 Thread Joseph Myers
On Sat, 26 Aug 2023, Martin Uecker via Gcc-patches wrote:

> -static int
> +static bool
>  comp_target_types (location_t location, tree ttl, tree ttr)

The comment above this function should be updated to refer to returning 
true, not to returning 1.  And other comments on common_pointer_type and 
inside that function should be updated to refer to comp_target_types 
returning true, not nonzero.

> @@ -1395,17 +1382,13 @@ free_all_tagged_tu_seen_up_to (const struct 
> tagged_tu_seen_cache *tu_til)
>  
>  /* Return 1 if two 'struct', 'union', or 'enum' types T1 and T2 are
> compatible.  If the two types are not the same (which has been
> -   checked earlier), this can only happen when multiple translation
> -   units are being compiled.  See C99 6.2.7 paragraph 1 for the exact
> -   rules.  ENUM_AND_INT_P and DIFFERENT_TYPES_P are as in
> -   comptypes_internal.  */
> +   checked earlier).  */
>  
> -static int
> +static bool
>  tagged_types_tu_compatible_p (const_tree t1, const_tree t2,
> -   bool *enum_and_int_p, bool *different_types_p)
> +   struct comptypes_data* data)

Similarly, this comment should be updated for the new return type.  Also 
the GNU style is "struct comptypes_data *data" with space before not after 
'*'.

> @@ -1631,9 +1603,9 @@ tagged_types_tu_compatible_p (const_tree t1, const_tree 
> t2,
> Otherwise, the argument types must match.
> ENUM_AND_INT_P and DIFFERENT_TYPES_P are as in comptypes_internal.  */
>  
> -static int
> +static bool
>  function_types_compatible_p (const_tree f1, const_tree f2,
> -  bool *enum_and_int_p, bool *different_types_p)
> +  struct comptypes_data *data)

Another comment to update for a changed return type.

>  /* Check two lists of types for compatibility, returning 0 for
> -   incompatible, 1 for compatible, or 2 for compatible with
> -   warning.  ENUM_AND_INT_P and DIFFERENT_TYPES_P are as in
> -   comptypes_internal.  */
> +   incompatible, 1 for compatible.  ENUM_AND_INT_P and
> +   DIFFERENT_TYPES_P are as in comptypes_internal.  */
>  
> -static int
> +static bool
>  type_lists_compatible_p (const_tree args1, const_tree args2,
> -  bool *enum_and_int_p, bool *different_types_p)
> +  struct comptypes_data *data)

This one also needs updating to remove references to parameters that no 
longer exist.

-- 
Joseph S. Myers
jos...@codesourcery.com


Re: [PATCH] fwprop: Allow UNARY_P and check register pressure.

2023-09-06 Thread Richard Sandiford via Gcc-patches
Robin Dapp  writes:
> Hi Richard,
>
> I did some testing with the attached v2 that does not restrict to UNARY
> anymore.  As feared ;) there is some more fallout that I'm detailing below.
>
> On Power there is one guality fail (pr43051-1.c) that I would take
> the liberty of ignoring for now.
>
> On x86 there are four fails:
>
>  - cond_op_addsubmuldiv__Float16-2.c: assembler error
>unsupported masking for `vmovsh'.  I guess that's a latent backend
>problem.
>
>  - ifcvt-3.c, pr49095.c: Here we propagate into a compare.  Before, we had
>(cmp (reg/CC) 0) and now we have (cmp (plus (reg1 reg2) 0).
>That looks like a costing problem and can hopefully solveable by making
>the second compare more expensive, preventing the propagation.
>i386 costing (or every costing?) is brittle so that could well break other
>things. 
>
>  - pr88873.c: This is interesting because even before this patch we
>propagated with different register classes (V2DF vs DI).  With the patch
>we check the register pressure, find the class NO_REGS for V2DF and
>abort (because the patch assumes NO_REGS = high pressure).  I'm thinking
>of keeping the old behavior for reg-reg propagations and only checking
>the pressure for more complex operations.
>
> aarch64 has the most fails:
>
>  - One guality fail (same as Power).
>  - shrn-combine-[123].c as before.
>
>  - A class of (hopefully, I only checked some) similar cases where we
>propagate an unspec_whilelo into an unspec_ptest.  Before we would only
>set a REG_EQUALS note.
>Before we managed to create a while_ultsivnx16bi_cc whereas now we have
>while_ultsivnx16bi and while_ultsivnx16bi_ptest that won't be combined.
>We create redundant whilelos and I'm not sure how to improve that. I
>guess a peephole is out of the question :)
>
>  - pred-combine-and.c: Here the new propagation appears useful at first.
>We propagate a "vector mask and" into a while_ultsivnx4bi_ptest and the
>individual and registers remain live up to the propagation site (while
>being dead before the patch).
>With the registers dead, combine could create a single fcmgt before.
>Now it only manages a 2->2 combination because we still need the registers
>and end up with two fcmgts.
>The code is worse but this seems more bad luck than anything.
>
>  - Addressing fails from before:  I looked into these and suspect all of
>them are a similar.
>What happens is that we have a poly_int offset that we shift, negate
>and then add to x0.  The result is used as load address.
>Before, we would pull (combine) the (plus x0 reg) into the load keeping
>the neg and shift.
>Now we propagate everything into a single (set (minus x0 offset)).
>The propagation itself seems worthwhile because we save one insn.
>However as we got rid of the base/offset split by lumping everything
>together, combine cannot pull the (plus) into the address load and
>we require an aarch64_split_add_offset.  This will emit the longer
>sequence of ashiftl and subtract.  The "base" address is x0 here so
>we cannot convert (minus x0 ...)) into neg.
>I didn't go through all of aarch64_split_add_offset.  I suppose we
>could re-add the separation of base/offset there but that might be
>a loss when the result is not used as an address. 
>
> Again, all in all no fatal problems but pretty annoying :)  It's not much
> but just gradually worse than with just UNARY.  Any idea on how/whether to
> continue?

Thanks for giving it a go.  Can you post the latest version of the
regpressure patch too?  The previous on-list version I could find
seems to be too old.

Thanks,
Richard

> Regards
>  Robin
>
> gcc/ChangeLog:
>
>   * fwprop.cc (fwprop_propagation::profitable_p): Add unary
>   handling.
>   (fwprop_propagation::update_register_pressure): New function.
>   (fwprop_propagation::register_pressure_high_p): New function
>   (reg_single_def_for_src_p): Look through unary expressions.
>   (try_fwprop_subst_pattern): Check register pressure.
>   (forward_propagate_into): Call new function.
>   (fwprop_init): Init register pressure.
>   (fwprop_done): Clean up register pressure.
>   (fwprop_insn): Add comment.
>
> gcc/testsuite/ChangeLog:
>
>   * gcc.target/riscv/rvv/autovec/binop/vadd-vx-fwprop.c: New test.
> ---
>  gcc/fwprop.cc | 359 +-
>  .../riscv/rvv/autovec/binop/vadd-vx-fwprop.c  |  64 
>  2 files changed, 419 insertions(+), 4 deletions(-)
>  create mode 100644 
> gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vadd-vx-fwprop.c
>
> diff --git a/gcc/fwprop.cc b/gcc/fwprop.cc
> index 0707a234726..ce6f5a74b00 100644
> --- a/gcc/fwprop.cc
> +++ b/gcc/fwprop.cc
> @@ -36,6 +36,10 @@ along with GCC; see the file COPYING3.  If not see
>  #include "tree-pass.h"
>  #include "rtl-iter.h"
>  #include "target.h"
> +#include "dominance.h"

Re: [PATCH v2] analyzer: Call off a superseding when diagnostics are unrelated [PR110830]

2023-09-06 Thread David Malcolm via Gcc-patches
On Wed, 2023-09-06 at 21:16 +0200, priour...@gmail.com wrote:

[...snip...]

> Signed-off-by: benjamin priour 
> Co-authored-by: david malcolm 

Please also add:

  Signed-off-by: David Malcolm 

[...snip...]

> 
> +static bool
> +compatible_epath_p (const exploded_path *lhs_path,
> +   const exploded_path *rhs_path)
> +{
> +  gcc_assert (lhs_path);
> +  gcc_assert (rhs_path);
> +  gcc_assert (rhs_path->length () > 0);
> +  gcc_assert (rhs_path->length () > 0);
> +  int lhs_eedge_idx = lhs_path->length () -1;
> +  int rhs_eedge_idx = rhs_path->length () -1;

Minor formatting nit: there should be a space between the '-' and the
'1' in the above lines, hence:

  int lhs_eedge_idx = lhs_path->length () - 1;
  int rhs_eedge_idx = rhs_path->length () - 1;

[...snip...]

OK for trunk with those changes

Thanks
Dave



Re: [PATCH] analyzer: Move gcc.dg/analyzer tests to c-c++-common (2) [PR96395]

2023-09-06 Thread David Malcolm via Gcc-patches
On Wed, 2023-09-06 at 15:50 +0200, Benjamin Priour wrote:
> Hi David,
> Thanks for the review.
> 
> 
> 
> On Tue, Sep 5, 2023 at 1:53 PM David Malcolm 
> wrote:
> 
> > On Mon, 2023-09-04 at 20:00 +0200, priour...@gmail.com wrote:
> > 
> > 
> [...snip...]
> 
> 
> > All of these "new" tests (apart from the "-noexcept" ones) look
> > like
> > they're meant to be existing tests that were moved, but where the
> > copy
> > of the test in gcc.dg/analyzer didn't get deleted, so they show up
> > as a
> > duplicate.  See the details below.
> > 
> 
> > >   * c-c++-common/analyzer/file-pr58237-noexcept.c: New test.
> > 
> > When duplicating a test like this, the test isn't entirely "new",
> > so
> > please say something like this in the ChangeLog entry, to make it
> > clear
> > where it came from:
> > 
> > 
> I actually wasn't sure about these -noexcept tests. They were part
> of gcc.dg/analyzer, thus only gcc was running them. Exceptions
> were not disabled *explicitly*, but since it was C, they weren't
> enabled
> either.
> 
> Therefore, the -noexcept tests are basically a copy, but with an
> explicit
> -fno-exceptions specification.
> When I duplicated them in that way I was thinking about making it
> clear
> that these tests fail in C++ with exceptions enabled, so that we
> would
> already
> have easy-to-spot failing tests to challenge a future exception
> support.

Ah, OK; let's go with your approach.

> 
> Though perhaps *not* duplicating the tests but rather simply specify
> -fno-exceptions,
> with a comment "Fails with exceptions" may be better.

[...snip...]

> > > @@ -45,7 +45,7 @@ void test(int n)
> > >    struct iter *it = iter_new (0, n, 1);
> > >    while (!iter_done_p (it))
> > >  {
> > > -  __analyzer_eval (it->val < n); /* { dg-warning "TRUE"
> > > "true" {
> > xfail *-*-* } } */
> > > +  __analyzer_eval (it->val < n); /* { dg-warning "TRUE"
> > > "true" } */
> > >    /* { dg-bogus "UNKNOWN" "unknown" { xfail *-*-* } .-1 } */
> > >    /* TODO(xfail^^^): ideally we ought to figure out i > 0
> > > after 1st
> > iteration.  */
> > > 
> > 
> > Presumably due to the change to
> > region_model::add_constraints_from_binop, right?
> > Looking at that dg-bogus "UNKNOWN", do we still get an UNKNOWN
> > here, or
> > can that line be removed?
> > If so, then the 3rd comment can presumably become:
> > 
> > 
> The bogus here still make sense - without it there is an excess error
> -.
> I had checked for it because I too thought it could be removed.
> If I remember it correctly, we get UNKNOWN during the widening pass.

(nods)

> 
> 
> > >    /* TODO: ideally we ought to figure out i > 0 after 1st
> > iteration.  */
> > 
> > [...snip...]
> > 
> > 
> > 
> [...snip...]
> 
> Thanks for spotting the files I forgot to remove from gcc.dg.
> Sorry about them, I had messed up my test folder when checking for
> arm-eabi,
> and I apparently missed some duplicates when retrieving my save.
> 
> As for the files the likes of inlining-*.c, i.e. noted as Moved
> to/...here.
> at the end of the ChangeLog, some tests checking for multiline
> outputs
> are so heavily rewritten than git marks them as Removed/New test
> instead of moved. I've manually edited that, but perhaps I shouldn't
> ?
> 
> I have successfully regstrapped the improvements you suggested.

Thanks.  Did you want me to doublecheck the updated patch?  Otherwise
feel free to push it to trunk.


> Part 3 of this serie of patches I hope will be regstrapped for
> Friday.

Thanks; I'm impressed at how much progress you've made on this problem.

Dave



Re: [PATCH 01/13] [APX EGPR] middle-end: Add insn argument to base_reg_class

2023-09-06 Thread Vladimir Makarov via Gcc-patches



On 9/1/23 05:07, Hongyu Wang wrote:

Uros Bizjak via Gcc-patches  于2023年8月31日周四 18:16写道:

On Thu, Aug 31, 2023 at 10:20 AM Hongyu Wang  wrote:

From: Kong Lingling 

Current reload infrastructure does not support selective base_reg_class
for backend insn. Add insn argument to base_reg_class for
lra/reload usage.

I don't think this is the correct approach. Ideally, a memory
constraint should somehow encode its BASE/INDEX register class.
Instead of passing "insn", simply a different constraint could be used
in the constraint string of the relevant insn.

We tried constraint only at the beginning, but then we found the
reload infrastructure
does not work like that.

The BASE/INDEX reg classes are determined before choosing alternatives, in
process_address under curr_insn_transform. Process_address creates the mem
operand according to the BASE/INDEX reg class. Then, the memory operand
constraint check will evaluate the mem op with targetm.legitimate_address_p.

If we want to make use of EGPR in base/index we need to either extend BASE/INDEX
reg class in the backend, or, for specific insns, add a target hook to
tell reload
that the extended reg class with EGPR can be used to construct memory operand.

CC'd Vladimir as git send-mail failed to add recipient.



I think the approach proposed by Intel developers is better.  In some way
we already use such approach when we pass memory mode to get the base
reg class.  Although we could use different memory constraints for
different modes when the possible base reg differs for some memory
modes.

Using special memory constraints probably can be implemented too (I
understand attractiveness of such approach for readability of the
machine description).  But in my opinion it will require much bigger
work in IRA/LRA/reload.  It also significantly slow down RA as we need
to process insn constraints for processing each memory in many places
(e.g. for calculation of reg classes and costs in IRA).  Still I think
there will be a few cases for this approach resulting in a bigger
probability of assigning hard reg out of specific base reg class and
this will result in additional reloads.

So the approach proposed by Intel is ok for me.  Although if x86 maintainers
are strongly against this approach and the changes in x86 machine
dependent code and Intel developers implement Uros approach, I am
ready to review this.  But still I prefer the current Intel developers
approach for reasons I mentioned above.



[PATCH v2] analyzer: Call off a superseding when diagnostics are unrelated [PR110830]

2023-09-06 Thread Benjamin Priour via Gcc-patches
From: benjamin priour 

Hi,

Second version of this patch after David's suggestions.
Thanks David for pointing out how I could implement it using sedges.
I hadn't thought of them being independent of the exploded path taken,
and unique for a conditional block's outcome. I had mistaken them with
eedges, those that we see in the *exploded*-graph, therefore since the
two saved_diagnostics can have arbitrary different paths I had to
use a nested loop.

It is much more efficient this way.

Regstrapped off trunk a7d052b3200c7928d903a0242b8cfd75d131e374 on
x86_64-linux-gnu.

Is it ready for trunk ?

Thanks,
Benjamin.

Patch below.
---

Before this patch, a saved_diagnostic would supersede another at
the same statement if and only its vfunc supercedes_p returned true
for the other diagnostic's kind.
That both warning were unrelated - i.e. resolving one would not fix
the other - was not considered in making the above choice.

This patch makes it so that two saved_diagnostics taking a different
outcome of at least one common conditional branching cannot supersede
each other.

Signed-off-by: benjamin priour 
Co-authored-by: david malcolm 

gcc/analyzer/ChangeLog:

PR analyzer/110830
* diagnostic-manager.cc
(compatible_epaths_p): New function.
(saved_diagnostic::supercedes_p): Now calls the above
to determine if the diagnostics do overlap and the superseding
may proceed.

gcc/testsuite/ChangeLog:

PR analyzer/110830
* c-c++-common/analyzer/pr110830.c: New test.
---
 gcc/analyzer/diagnostic-manager.cc|  90 +-
 .../c-c++-common/analyzer/pr110830.c  | 111 ++
 2 files changed, 200 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/c-c++-common/analyzer/pr110830.c

diff --git a/gcc/analyzer/diagnostic-manager.cc 
b/gcc/analyzer/diagnostic-manager.cc
index 10fea486b8c..90c56a350e7 100644
--- a/gcc/analyzer/diagnostic-manager.cc
+++ b/gcc/analyzer/diagnostic-manager.cc
@@ -887,6 +887,88 @@ saved_diagnostic::add_duplicate (saved_diagnostic *other)
   m_duplicates.safe_push (other);
 }
 
+/* Walk up the sedges of each of the two paths.
+   If the two sequences of sedges do not perfectly correspond,
+   then paths are incompatible.
+   If there is at least one sedge that either cannot be paired up
+   or its counterpart is not equal, then the paths are incompatible
+   and this function returns FALSE.
+   Otherwise return TRUE.
+
+   Incompatible paths:
+
+   
+   /  \
+  /\
+true  false
+ |  |
+......
+ |  |
+...   stmt x
+ |
+   stmt x
+
+   Both LHS_PATH and RHS_PATH final enodes should be
+   over the same gimple statement.  */
+
+static bool
+compatible_epath_p (const exploded_path *lhs_path,
+   const exploded_path *rhs_path)
+{
+  gcc_assert (lhs_path);
+  gcc_assert (rhs_path);
+  gcc_assert (rhs_path->length () > 0);
+  gcc_assert (rhs_path->length () > 0);
+  int lhs_eedge_idx = lhs_path->length () -1;
+  int rhs_eedge_idx = rhs_path->length () -1;
+  const exploded_edge *lhs_eedge;
+  const exploded_edge *rhs_eedge;
+
+  while (lhs_eedge_idx >= 0 && rhs_eedge_idx >= 0)
+{
+  while (lhs_eedge_idx >= 0)
+   {
+ /* Find LHS_PATH's next superedge.  */
+ lhs_eedge = lhs_path->m_edges[lhs_eedge_idx];
+ if (lhs_eedge->m_sedge)
+   break;
+ else
+   lhs_eedge_idx--;
+   }
+  while (rhs_eedge_idx >= 0)
+   {
+ /* Find RHS_PATH's next superedge.  */
+ rhs_eedge = rhs_path->m_edges[rhs_eedge_idx];
+ if (rhs_eedge->m_sedge)
+   break;
+ else
+   rhs_eedge_idx--;
+   }
+
+  if (lhs_eedge->m_sedge && rhs_eedge->m_sedge)
+   {
+ if (lhs_eedge->m_sedge != rhs_eedge->m_sedge)
+   /* Both superedges do not match.
+  Superedges are not dependent on the exploded path, so even
+  different epaths will have similar sedges if they follow
+  the same outcome of a conditional node.  */
+   return false;
+
+ lhs_eedge_idx--;
+ rhs_eedge_idx--;
+ continue;
+   }
+  else if (lhs_eedge->m_sedge == nullptr && rhs_eedge->m_sedge == nullptr)
+   /* Both paths were drained up entirely.
+  No discriminant was found.  */
+   return true;
+
+  /* A superedge was found for only one of the two paths.  */
+  return false;
+}
+}
+
+
 /* Return true if this diagnostic supercedes OTHER, and that OTHER should
therefore not be emitted.  */
 
@@ -896,7 +978,13 @@ saved_diagnostic::supercedes_p (const saved_diagnostic 
) const
   /* They should be at the same stmt.  */
   if (m_stmt != other.m_stmt)
 return false;
-  return m_d->supercedes_p (*other.m_d);
+  /* return early if OTHER won't be superseded anyway.  */
+  if (!m_d->supercedes_p (*other.m_d))
+return false;
+
+  /* If the two 

Re: [PATCH v2 1/2] riscv: Add support for strlen inline expansion

2023-09-06 Thread Palmer Dabbelt

On Wed, 06 Sep 2023 09:47:05 PDT (-0700), jeffreya...@gmail.com wrote:



On 9/6/23 10:22, Palmer Dabbelt wrote:

On Wed, 06 Sep 2023 09:07:33 PDT (-0700), christoph.muell...@vrull.eu
wrote:

From: Christoph Müllner 

This patch implements the expansion of the strlen builtin for RV32/RV64
for xlen-aligned aligned strings if Zbb or XTheadBb instructions are
available.
The inserted sequences are:

rv32gc_zbb (RV64 is similar):
  add a3,a0,4
  li  a4,-1
.L1:  lw  a5,0(a0)
  add a0,a0,4
  orc.b   a5,a5
  beq a5,a4,.L1
  not a5,a5
  ctz a5,a5
  srl a5,a5,0x3
  add a0,a0,a5
  sub a0,a0,a3

rv64gc_xtheadbb (RV32 is similar):
  add   a4,a0,8
.L2:  ld    a5,0(a0)
  add   a0,a0,8
  th.tstnbz a5,a5
  beqz  a5,.L2
  th.rev    a5,a5
  th.ff1    a5,a5
  srl   a5,a5,0x3
  add   a0,a0,a5
  sub   a0,a0,a4

This allows to inline calls to strlen(), with optimized code for
xlen-aligned strings, resulting in the following benefits over
a call to libc:
* no call/ret instructions
* no stack frame allocation
* no register saving/restoring
* no alignment test

The inlining mechanism is gated by a new switch ('-minline-strlen')
and by the variable 'optimize_size'.


Maybe this is more of a Jeff question, but this looks to me like
something that should be target-agnostic -- maybe we need some backend
work to actually emit the special instruction, but IIRC this is a
somewhat common flavor of instruction and is in other ISAs as well.  It
looks like there's already a strlen insn, so I guess the core issue is
why we need that unspec?

Sorry if I'm just missing something, though...


The generic strlen expansion in GCC doesn't really expand a strlen loop.
  It really just calls into the target code and forces the target to
handle everything.


OK, that explains it.


We could have generic strlen expansion code that kicks in if the target
expander fails.  And we could probably create the necessary opcodes to
express the optimized end-of-string comparison instructions that exist
on various architectures.  I'm not not sure it's worth that much effort
given targets are already doing their own strlen expansions.



If everyone does it this way then I don't think we need to worry about 
it.




jeff


libgo patch committed: permit $AR to include options

2023-09-06 Thread Ian Lance Taylor via Gcc-patches
This libgo patch changes the go tool to permit the AR environment
variable to include options.  This mirrors the way it already handles
the CC environment variable.

This ports https://go.dev/cl/526275 to the gofrontend repo.

This is needed for gccgo testing because the top-level GCC Makefile
now passes a --plugin option to ar if it supports one.

Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
dab7163feedc99bd94549ee490031f86f8d0a6ca
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 83ab3e2d64c..30710e856cb 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-d04b024021bb7dbaa434a6d902bd12beb08e315f
+53cdfab53ce79d8dfc1df01a696d4ffc43f17c3d
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/go/cmd/go/internal/work/gccgo.go 
b/libgo/go/cmd/go/internal/work/gccgo.go
index c1026c71e01..3e07f8791eb 100644
--- a/libgo/go/cmd/go/internal/work/gccgo.go
+++ b/libgo/go/cmd/go/internal/work/gccgo.go
@@ -45,12 +45,8 @@ func (gccgoToolchain) linker() string {
return GccgoBin
 }
 
-func (gccgoToolchain) ar() string {
-   ar := cfg.Getenv("AR")
-   if ar == "" {
-   ar = "ar"
-   }
-   return ar
+func (gccgoToolchain) ar() []string {
+   return envList("AR", "ar")
 }
 
 func checkGccgoBin() {


[PATCH 5/5] RISC-V: Remove Assert Protecting Types

2023-09-06 Thread Edwin Lu
This patch turns on the assert which ensures every instruction has type
that is not TYPE_UNKNOWN.

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_sched_variable_issue): Remove assert

Signed-off-by: Edwin Lu 
---
 gcc/config/riscv/riscv.cc | 2 --
 1 file changed, 2 deletions(-)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index ef63079de8e..f0576351cda 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -7330,11 +7330,9 @@ riscv_sched_variable_issue (FILE *, int, rtx_insn *insn, 
int more)
   if (get_attr_type (insn) == TYPE_GHOST)
 return 0;
 
-#if 0
   /* If we ever encounter an insn with an unknown type, trip
  an assert so we can find and fix this problem.  */
   gcc_assert (get_attr_type (insn) != TYPE_UNKNOWN);
-#endif
 
   return more - 1;
 }
-- 
2.34.1



[PATCH 3/5] RISC-V: Add Types to Un-Typed Zicond Instructions

2023-09-06 Thread Edwin Lu
This patch creates a new "zicond" type and updates all zicond instructions
with that type.

gcc/ChangeLog:

* config/riscv/riscv.md: Add "zicond" type
* config/riscv/zicond.md: Update types

Signed-off-by: Edwin Lu 
---
 gcc/config/riscv/riscv.md  | 5 +++--
 gcc/config/riscv/zicond.md | 8 
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index 6684ad89cff..c329f55db43 100644
--- a/gcc/config/riscv/riscv.md
+++ b/gcc/config/riscv/riscv.md
@@ -313,6 +313,7 @@ (define_attr "ext_enabled" "no,yes"
 ;; cbocache block instructions
 ;; crypto cryptography instructions
 ;; csrcode size reduction instructions
+;; zicondzicond instructions
 ;; Classification of RVV instructions which will be added to each RVV .md 
pattern and used by scheduler.
 ;; rdvlenb vector byte length vlenb csrr read
 ;; rdvlvector length vl csrr read
@@ -422,8 +423,8 @@ (define_attr "type"
mtc,mfc,const,arith,logical,shift,slt,imul,idiv,move,fmove,fadd,fmul,
fmadd,fdiv,fcmp,fcvt,fsqrt,multi,auipc,sfb_alu,nop,trap,ghost,bitmanip,
rotate,clmul,min,max,minu,maxu,clz,ctz,cpop,
-   atomic,condmove,cbo,crypto,csr,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm,vsetvl,
-   vlde,vste,vldm,vstm,vlds,vsts,
+   atomic,condmove,cbo,crypto,csr,zicond,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm,
+   vsetvl, vlde,vste,vldm,vstm,vlds,vsts,
vldux,vldox,vstux,vstox,vldff,vldr,vstr,

vlsegde,vssegte,vlsegds,vssegts,vlsegdux,vlsegdox,vssegtux,vssegtox,vlsegdff,
vialu,viwalu,vext,vicalu,vshift,vnshift,vicmp,viminmax,
diff --git a/gcc/config/riscv/zicond.md b/gcc/config/riscv/zicond.md
index 1721e1011ea..0269bd14399 100644
--- a/gcc/config/riscv/zicond.md
+++ b/gcc/config/riscv/zicond.md
@@ -30,7 +30,7 @@ (define_insn "*czero.."
   (const_int 0)))]
   "TARGET_ZICOND"
   "czero.\t%0,%2,%1"
-)
+[(set_attr "type" "zicond")])
 
 (define_insn "*czero.."
   [(set (match_operand:GPR 0 "register_operand" "=r")
@@ -40,7 +40,7 @@ (define_insn "*czero.."
   (match_operand:GPR 2 "register_operand"   "r")))]
   "TARGET_ZICOND"
   "czero.\t%0,%2,%1"
-)
+[(set_attr "type" "zicond")])
 
 ;; Special optimization under eq/ne in primitive semantics
 (define_insn "*czero.eqz..opt1"
@@ -51,7 +51,7 @@ (define_insn "*czero.eqz..opt1"
   (match_operand:GPR 3 "register_operand" "r")))]
   "TARGET_ZICOND && rtx_equal_p (operands[1], operands[2])"
   "czero.eqz\t%0,%3,%1"
-)
+[(set_attr "type" "zicond")])
 
 (define_insn "*czero.nez..opt2"
   [(set (match_operand:GPR 0 "register_operand"   "=r")
@@ -61,7 +61,7 @@ (define_insn "*czero.nez..opt2"
   (match_operand:GPR 3 "register_operand" "1")))]
   "TARGET_ZICOND && rtx_equal_p (operands[1], operands[3])"
   "czero.eqz\t%0,%2,%1"
-)
+[(set_attr "type" "zicond")])
 
 ;; Combine creates this form in some cases (particularly the coremark
 ;; CRC loop.
-- 
2.34.1



[PATCH 4/5] RISC-V: Update Types for RISC-V Instructions

2023-09-06 Thread Edwin Lu
This patch adds types to riscv instructions that were added or were
missed by the original patch
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628996.html

gcc/ChangeLog:

* config/riscv/riscv.md: Update types

Signed-off-by: Edwin Lu 
---
 gcc/config/riscv/riscv.md | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index c329f55db43..c1cecd27815 100644
--- a/gcc/config/riscv/riscv.md
+++ b/gcc/config/riscv/riscv.md
@@ -2223,6 +2223,7 @@ (define_insn "movsidf2_low_rv32"
   "TARGET_HARD_FLOAT && !TARGET_64BIT && TARGET_ZFA"
   "fmv.x.w\t%0,%1"
   [(set_attr "move_type" "fmove")
+   (set_attr "type" "fmove")
(set_attr "mode" "DF")])
 
 
@@ -2235,6 +2236,7 @@ (define_insn "movsidf2_high_rv32"
   "TARGET_HARD_FLOAT && !TARGET_64BIT && TARGET_ZFA"
   "fmvh.x.d\t%0,%1"
   [(set_attr "move_type" "fmove")
+   (set_attr "type" "fmove")
(set_attr "mode" "DF")])
 
 (define_insn "movdfsisi3_rv32"
@@ -2247,6 +2249,7 @@ (define_insn "movdfsisi3_rv32"
   "TARGET_HARD_FLOAT && !TARGET_64BIT && TARGET_ZFA"
   "fmvp.d.x\t%0,%2,%1"
   [(set_attr "move_type" "fmove")
+   (set_attr "type" "fmove")
(set_attr "mode" "DF")])
 
 (define_split
-- 
2.34.1



[PATCH 2/5] RISC-V: Add Types for Un-Typed zc Instructions

2023-09-06 Thread Edwin Lu
This patch adds types to the untyped zc instructions. Creates a new
type "csr" for these instructions for now.

gcc/ChangeLog:

* config/riscv/riscv.md: Add "csr" type
* config/riscv/zc.md: Update types

Signed-off-by: Edwin Lu 
---
 gcc/config/riscv/riscv.md |   3 +-
 gcc/config/riscv/zc.md| 102 +++---
 2 files changed, 54 insertions(+), 51 deletions(-)

diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index d80b6938f84..6684ad89cff 100644
--- a/gcc/config/riscv/riscv.md
+++ b/gcc/config/riscv/riscv.md
@@ -312,6 +312,7 @@ (define_attr "ext_enabled" "no,yes"
 ;; condmoveconditional moves
 ;; cbocache block instructions
 ;; crypto cryptography instructions
+;; csrcode size reduction instructions
 ;; Classification of RVV instructions which will be added to each RVV .md 
pattern and used by scheduler.
 ;; rdvlenb vector byte length vlenb csrr read
 ;; rdvlvector length vl csrr read
@@ -421,7 +422,7 @@ (define_attr "type"
mtc,mfc,const,arith,logical,shift,slt,imul,idiv,move,fmove,fadd,fmul,
fmadd,fdiv,fcmp,fcvt,fsqrt,multi,auipc,sfb_alu,nop,trap,ghost,bitmanip,
rotate,clmul,min,max,minu,maxu,clz,ctz,cpop,
-   atomic,condmove,cbo,crypto,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm,vsetvl,
+   atomic,condmove,cbo,crypto,csr,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm,vsetvl,
vlde,vste,vldm,vstm,vlds,vsts,
vldux,vldox,vstux,vstox,vldff,vldr,vstr,

vlsegde,vssegte,vlsegds,vssegts,vlsegdux,vlsegdox,vssegtux,vssegtox,vlsegdff,
diff --git a/gcc/config/riscv/zc.md b/gcc/config/riscv/zc.md
index 77b28adde95..86f1afd66cb 100644
--- a/gcc/config/riscv/zc.md
+++ b/gcc/config/riscv/zc.md
@@ -27,7 +27,7 @@ (define_insn "@gpr_multi_pop_up_to_ra_"
(const_int ]
   "TARGET_ZCMP"
   "cm.pop  {ra}, %0"
-)
+[(set_attr "type" "csr")])
 
 (define_insn "@gpr_multi_pop_up_to_s0_"
   [(set (reg:X SP_REGNUM)
@@ -41,7 +41,7 @@ (define_insn "@gpr_multi_pop_up_to_s0_"
(const_int ]
   "TARGET_ZCMP"
   "cm.pop  {ra, s0}, %0"
-)
+[(set_attr "type" "csr")])
 
 (define_insn "@gpr_multi_pop_up_to_s1_"
   [(set (reg:X SP_REGNUM)
@@ -58,7 +58,7 @@ (define_insn "@gpr_multi_pop_up_to_s1_"
(const_int ]
   "TARGET_ZCMP"
   "cm.pop  {ra, s0-s1}, %0"
-)
+[(set_attr "type" "csr")])
 
 (define_insn "@gpr_multi_pop_up_to_s2_"
   [(set (reg:X SP_REGNUM)
@@ -78,7 +78,7 @@ (define_insn "@gpr_multi_pop_up_to_s2_"
(const_int ]
   "TARGET_ZCMP"
   "cm.pop  {ra, s0-s2}, %0"
-)
+[(set_attr "type" "csr")])
 
 (define_insn "@gpr_multi_pop_up_to_s3_"
   [(set (reg:X SP_REGNUM)
@@ -101,7 +101,7 @@ (define_insn "@gpr_multi_pop_up_to_s3_"
(const_int ]
   "TARGET_ZCMP"
   "cm.pop  {ra, s0-s3}, %0"
-)
+[(set_attr "type" "csr")])
 
 (define_insn "@gpr_multi_pop_up_to_s4_"
   [(set (reg:X SP_REGNUM)
@@ -127,7 +127,7 @@ (define_insn "@gpr_multi_pop_up_to_s4_"
(const_int ]
   "TARGET_ZCMP"
   "cm.pop  {ra, s0-s4}, %0"
-)
+[(set_attr "type" "csr")])
 
 (define_insn "@gpr_multi_pop_up_to_s5_"
   [(set (reg:X SP_REGNUM)
@@ -156,7 +156,7 @@ (define_insn "@gpr_multi_pop_up_to_s5_"
(const_int ]
   "TARGET_ZCMP"
   "cm.pop  {ra, s0-s5}, %0"
-)
+[(set_attr "type" "csr")])
 
 (define_insn "@gpr_multi_pop_up_to_s6_"
   [(set (reg:X SP_REGNUM)
@@ -188,7 +188,7 @@ (define_insn "@gpr_multi_pop_up_to_s6_"
(const_int ]
   "TARGET_ZCMP"
   "cm.pop  {ra, s0-s6}, %0"
-)
+[(set_attr "type" "csr")])
 
 (define_insn "@gpr_multi_pop_up_to_s7_"
   [(set (reg:X SP_REGNUM)
@@ -223,7 +223,7 @@ (define_insn "@gpr_multi_pop_up_to_s7_"
   (const_int ]
   "TARGET_ZCMP"
   "cm.pop  {ra, s0-s7}, %0"
-)
+[(set_attr "type" "csr")])
 
 (define_insn "@gpr_multi_pop_up_to_s8_"
   [(set (reg:X SP_REGNUM)
@@ -261,7 +261,7 @@ (define_insn "@gpr_multi_pop_up_to_s8_"
(const_int ]
   "TARGET_ZCMP"
   "cm.pop  {ra, s0-s8}, %0"
-)
+[(set_attr "type" "csr")])
 
 (define_insn "@gpr_multi_pop_up_to_s9_"
   [(set (reg:X SP_REGNUM)
@@ -302,7 +302,7 @@ (define_insn "@gpr_multi_pop_up_to_s9_"
(const_int ]
   "TARGET_ZCMP"
   "cm.pop  {ra, s0-s9}, %0"
-)
+[(set_attr "type" "csr")])
 
 (define_insn "@gpr_multi_pop_up_to_s11_"
   [(set (reg:X SP_REGNUM)
@@ -349,7 +349,7 @@ (define_insn "@gpr_multi_pop_up_to_s11_"
(const_int ]
   "TARGET_ZCMP"
   "cm.pop  {ra, s0-s11}, %0"
-)
+[(set_attr "type" "csr")])
 
 (define_insn "@gpr_multi_popret_up_to_ra_"
   [(set (reg:X SP_REGNUM)
@@ -362,7 +362,7 @@ (define_insn "@gpr_multi_popret_up_to_ra_"
(use (reg:SI RETURN_ADDR_REGNUM))]
   "TARGET_ZCMP"
   "cm.popret   {ra}, %0"
-)
+[(set_attr "type" "csr")])
 
 (define_insn "@gpr_multi_popret_up_to_s0_"
   [(set (reg:X SP_REGNUM)
@@ -378,7 +378,7 @@ (define_insn 

[PATCH 1/5] RISC-V: Update Types for Vector Instructions

2023-09-06 Thread Edwin Lu
This patch adds types to vector instructions that were added after or were
missed by the original patch 
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628594.html

gcc/ChangeLog:

* config/riscv/autovec-opt.md: Update types
* config/riscv/autovec.md: likewise

Signed-off-by: Edwin Lu 
---
 gcc/config/riscv/autovec-opt.md | 42 ++---
 gcc/config/riscv/autovec.md | 28 +++---
 2 files changed, 47 insertions(+), 23 deletions(-)

diff --git a/gcc/config/riscv/autovec-opt.md b/gcc/config/riscv/autovec-opt.md
index 1ca5ce97193..6cc1a01629c 100644
--- a/gcc/config/riscv/autovec-opt.md
+++ b/gcc/config/riscv/autovec-opt.md
@@ -728,7 +728,8 @@ (define_insn_and_split "*cond_abs"
 gen_int_mode (GET_MODE_NUNITS 
(mode), Pmode),
 const0_rtx));
   DONE;
-})
+}
+[(set_attr "type" "vector")])
 
 ;; Combine vlmax neg and UNSPEC_VCOPYSIGN
 (define_insn_and_split "*copysign_neg"
@@ -746,7 +747,8 @@ (define_insn_and_split "*copysign_neg"
   riscv_vector::emit_vlmax_insn (code_for_pred_ncopysign (mode),
   riscv_vector::BINARY_OP, operands);
   DONE;
-})
+}
+[(set_attr "type" "vector")])
 
 ;; Combine sign_extend/zero_extend(vf2) and vcond_mask
 (define_insn_and_split "*cond_"
@@ -765,7 +767,8 @@ (define_insn_and_split "*cond_"
gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
   riscv_vector::expand_cond_len_unop (icode, ops);
   DONE;
-})
+}
+[(set_attr "type" "vector")])
 
 ;; Combine sign_extend/zero_extend(vf4) and vcond_mask
 (define_insn_and_split "*cond_"
@@ -784,7 +787,8 @@ (define_insn_and_split "*cond_"
gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
   riscv_vector::expand_cond_len_unop (icode, ops);
   DONE;
-})
+}
+[(set_attr "type" "vector")])
 
 ;; Combine sign_extend/zero_extend(vf8) and vcond_mask
 (define_insn_and_split "*cond_"
@@ -803,7 +807,8 @@ (define_insn_and_split "*cond_"
gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
   riscv_vector::expand_cond_len_unop (icode, ops);
   DONE;
-})
+}
+[(set_attr "type" "vector")])
 
 ;; Combine trunc(vf2) + vcond_mask
 (define_insn_and_split "*cond_trunc"
@@ -823,7 +828,8 @@ (define_insn_and_split "*cond_trunc"
gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
   riscv_vector::expand_cond_len_unop (icode, ops);
   DONE;
-})
+}
+[(set_attr "type" "vector")])
 
 ;; Combine FP sign_extend/zero_extend(vf2) and vcond_mask
 (define_insn_and_split "*cond_extend"
@@ -842,7 +848,8 @@ (define_insn_and_split "*cond_extend"
gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
   riscv_vector::expand_cond_len_unop (icode, ops);
   DONE;
-})
+}
+[(set_attr "type" "vector")])
 
 ;; Combine FP trunc(vf2) + vcond_mask
 (define_insn_and_split "*cond_trunc"
@@ -862,7 +869,8 @@ (define_insn_and_split "*cond_trunc"
gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
   riscv_vector::expand_cond_len_unop (icode, ops);
   DONE;
-})
+}
+[(set_attr "type" "vector")])
 
 ;; Combine convert(FP->INT) + vcond_mask
 (define_insn_and_split "*cond_"
@@ -882,7 +890,8 @@ (define_insn_and_split "*cond_"
gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
   riscv_vector::expand_cond_len_unop (icode, ops);
   DONE;
-})
+}
+[(set_attr "type" "vector")])
 
 ;; Combine convert(INT->FP) + vcond_mask
 (define_insn_and_split "*cond_"
@@ -902,7 +911,8 @@ (define_insn_and_split "*cond_"
gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
   riscv_vector::expand_cond_len_unop (icode, ops);
   DONE;
-})
+}
+[(set_attr "type" "vector")])
 
 ;; Combine convert(FP->2xINT) + vcond_mask
 (define_insn_and_split "*cond_"
@@ -922,7 +932,8 @@ (define_insn_and_split "*cond_"
gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
   riscv_vector::expand_cond_len_unop (icode, ops);
   DONE;
-})
+}
+[(set_attr "type" "vector")])
 
 ;; Combine convert(INT->2xFP) + vcond_mask
 (define_insn_and_split "*cond_"
@@ -942,7 +953,8 @@ (define_insn_and_split "*cond_"
gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
   riscv_vector::expand_cond_len_unop (icode, ops);
   DONE;
-})
+}
+[(set_attr "type" "vector")])
 
 ;; Combine convert(2xFP->INT) + vcond_mask
 (define_insn_and_split "*cond_"
@@ -962,7 +974,8 @@ (define_insn_and_split "*cond_"
gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
   riscv_vector::expand_cond_len_unop (icode, ops);
   DONE;
-})
+}
+[(set_attr "type" "vector")])
 
 ;; Combine convert(2xINT->FP) + vcond_mask
 (define_insn_and_split "*cond_2"
@@ -982,4 +995,5 @@ (define_insn_and_split "*cond_2"
gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
   riscv_vector::expand_cond_len_unop (icode, ops);
   DONE;
-})
+}
+[(set_attr "type" "vector")])
diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
index 0f9d1fe2c8e..047a66b238f 100644
--- a/gcc/config/riscv/autovec.md
+++ 

[PATCH 0/5] RISC-V: Add Types to Untyped Instructions

2023-09-06 Thread Edwin Lu
This series adds types to the remaining untyped instructions.

Related Discussion:
https://inbox.sourceware.org/gcc-patches/12fb5088-3f28-0a69-de1e-f387371a5...@gmail.com/

Also enables assert which checks to make sure every instruction has a type

All patches were tested with rv32/rv64 linux/newlib multilib
Additional extensions tested:
gcv
gc_zba_zbb_zbc_zbs

Edwin Lu (5):
  RISC-V: Update Types for Vector Instructions
  RISC-V: Add Types for Un-Typed zc Instructions
  RISC-V: Add Types to Un-Typed Zicond Instructions
  RISC-V: Add Types to Un-Typed Zicond Instructions
  RISC-V: Remove Assert Protecting Types

 gcc/config/riscv/autovec-opt.md |  42 -
 gcc/config/riscv/autovec.md |  28 ++---
 gcc/config/riscv/riscv.cc   |   2 -
 gcc/config/riscv/riscv.md   |   9 ++-
 gcc/config/riscv/zc.md  | 102 
 gcc/config/riscv/zicond.md  |   8 +--
 6 files changed, 110 insertions(+), 81 deletions(-)

-- 
2.34.1



Re: [PATCH v2 1/2] riscv: Add support for strlen inline expansion

2023-09-06 Thread Jeff Law via Gcc-patches




On 9/6/23 10:22, Palmer Dabbelt wrote:
On Wed, 06 Sep 2023 09:07:33 PDT (-0700), christoph.muell...@vrull.eu 
wrote:

From: Christoph Müllner 

This patch implements the expansion of the strlen builtin for RV32/RV64
for xlen-aligned aligned strings if Zbb or XTheadBb instructions are 
available.

The inserted sequences are:

rv32gc_zbb (RV64 is similar):
  add a3,a0,4
  li  a4,-1
.L1:  lw  a5,0(a0)
  add a0,a0,4
  orc.b   a5,a5
  beq a5,a4,.L1
  not a5,a5
  ctz a5,a5
  srl a5,a5,0x3
  add a0,a0,a5
  sub a0,a0,a3

rv64gc_xtheadbb (RV32 is similar):
  add   a4,a0,8
.L2:  ld    a5,0(a0)
  add   a0,a0,8
  th.tstnbz a5,a5
  beqz  a5,.L2
  th.rev    a5,a5
  th.ff1    a5,a5
  srl   a5,a5,0x3
  add   a0,a0,a5
  sub   a0,a0,a4

This allows to inline calls to strlen(), with optimized code for
xlen-aligned strings, resulting in the following benefits over
a call to libc:
* no call/ret instructions
* no stack frame allocation
* no register saving/restoring
* no alignment test

The inlining mechanism is gated by a new switch ('-minline-strlen')
and by the variable 'optimize_size'.


Maybe this is more of a Jeff question, but this looks to me like 
something that should be target-agnostic -- maybe we need some backend 
work to actually emit the special instruction, but IIRC this is a 
somewhat common flavor of instruction and is in other ISAs as well.  It 
looks like there's already a strlen insn, so I guess the core issue is 
why we need that unspec?


Sorry if I'm just missing something, though...


The generic strlen expansion in GCC doesn't really expand a strlen loop. 
 It really just calls into the target code and forces the target to 
handle everything.



We could have generic strlen expansion code that kicks in if the target 
expander fails.  And we could probably create the necessary opcodes to 
express the optimized end-of-string comparison instructions that exist 
on various architectures.  I'm not not sure it's worth that much effort 
given targets are already doing their own strlen expansions.


jeff


Re: [PATCH v2 1/2] riscv: Add support for strlen inline expansion

2023-09-06 Thread Palmer Dabbelt

On Wed, 06 Sep 2023 09:07:33 PDT (-0700), christoph.muell...@vrull.eu wrote:

From: Christoph Müllner 

This patch implements the expansion of the strlen builtin for RV32/RV64
for xlen-aligned aligned strings if Zbb or XTheadBb instructions are available.
The inserted sequences are:

rv32gc_zbb (RV64 is similar):
  add a3,a0,4
  li  a4,-1
.L1:  lw  a5,0(a0)
  add a0,a0,4
  orc.b   a5,a5
  beq a5,a4,.L1
  not a5,a5
  ctz a5,a5
  srl a5,a5,0x3
  add a0,a0,a5
  sub a0,a0,a3

rv64gc_xtheadbb (RV32 is similar):
  add   a4,a0,8
.L2:  lda5,0(a0)
  add   a0,a0,8
  th.tstnbz a5,a5
  beqz  a5,.L2
  th.reva5,a5
  th.ff1a5,a5
  srl   a5,a5,0x3
  add   a0,a0,a5
  sub   a0,a0,a4

This allows to inline calls to strlen(), with optimized code for
xlen-aligned strings, resulting in the following benefits over
a call to libc:
* no call/ret instructions
* no stack frame allocation
* no register saving/restoring
* no alignment test

The inlining mechanism is gated by a new switch ('-minline-strlen')
and by the variable 'optimize_size'.


Maybe this is more of a Jeff question, but this looks to me like 
something that should be target-agnostic -- maybe we need some backend 
work to actually emit the special instruction, but IIRC this is a 
somewhat common flavor of instruction and is in other ISAs as well.  It 
looks like there's already a strlen insn, so I guess the core issue is 
why we need that unspec?


Sorry if I'm just missing something, though...


Tested using the glibc string tests.

Signed-off-by: Christoph Müllner 

gcc/ChangeLog:

* config.gcc: Add new object riscv-string.o.
riscv-string.cc.
* config/riscv/riscv-protos.h (riscv_expand_strlen):
New function.
* config/riscv/riscv.md (strlen): New expand INSN.
* config/riscv/riscv.opt: New flag 'minline-strlen'.
* config/riscv/t-riscv: Add new object riscv-string.o.
* config/riscv/thead.md (th_rev2): Export INSN name.
(th_rev2): Likewise.
(th_tstnbz2): New INSN.
* doc/invoke.texi: Document '-minline-strlen'.
* emit-rtl.cc (emit_likely_jump_insn): New helper function.
(emit_unlikely_jump_insn): Likewise.
* rtl.h (emit_likely_jump_insn): New prototype.
(emit_unlikely_jump_insn): Likewise.
* config/riscv/riscv-string.cc: New file.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/xtheadbb-strlen-unaligned.c: New test.
* gcc.target/riscv/xtheadbb-strlen.c: New test.
* gcc.target/riscv/zbb-strlen-disabled-2.c: New test.
* gcc.target/riscv/zbb-strlen-disabled.c: New test.
* gcc.target/riscv/zbb-strlen-unaligned.c: New test.
* gcc.target/riscv/zbb-strlen.c: New test.
---
 gcc/config.gcc|   3 +-
 gcc/config/riscv/riscv-protos.h   |   3 +
 gcc/config/riscv/riscv-string.cc  | 183 ++
 gcc/config/riscv/riscv.md |  28 +++
 gcc/config/riscv/riscv.opt|   4 +
 gcc/config/riscv/t-riscv  |   6 +
 gcc/config/riscv/thead.md |   9 +-
 gcc/doc/invoke.texi   |  11 +-
 gcc/emit-rtl.cc   |  24 +++
 gcc/rtl.h |   2 +
 .../riscv/xtheadbb-strlen-unaligned.c |  14 ++
 .../gcc.target/riscv/xtheadbb-strlen.c|  19 ++
 .../gcc.target/riscv/zbb-strlen-disabled-2.c  |  15 ++
 .../gcc.target/riscv/zbb-strlen-disabled.c|  15 ++
 .../gcc.target/riscv/zbb-strlen-unaligned.c   |  14 ++
 gcc/testsuite/gcc.target/riscv/zbb-strlen.c   |  19 ++
 16 files changed, 366 insertions(+), 3 deletions(-)
 create mode 100644 gcc/config/riscv/riscv-string.cc
 create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadbb-strlen-unaligned.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadbb-strlen.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen-disabled-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen-disabled.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen-unaligned.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen.c

diff --git a/gcc/config.gcc b/gcc/config.gcc
index b2fe7c7ceef..aff6b6a5601 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -530,7 +530,8 @@ pru-*-*)
;;
 riscv*)
cpu_type=riscv
-   extra_objs="riscv-builtins.o riscv-c.o riscv-sr.o riscv-shorten-memrefs.o 
riscv-selftests.o riscv-v.o riscv-vsetvl.o riscv-vector-costs.o"
+   extra_objs="riscv-builtins.o riscv-c.o riscv-sr.o riscv-shorten-memrefs.o 
riscv-selftests.o riscv-string.o"
+   extra_objs="${extra_objs} riscv-v.o riscv-vsetvl.o riscv-vector-costs.o"
extra_objs="${extra_objs} riscv-vector-builtins.o 
riscv-vector-builtins-shapes.o riscv-vector-builtins-bases.o"
   

[committed 19/12] Additional _BitInt test coverage [PR102989]

2023-09-06 Thread Jakub Jelinek via Gcc-patches
On Tue, Sep 05, 2023 at 10:40:26PM +, Joseph Myers wrote:
> Additional tests I think should be added (for things I expect should 
> already work):
> 
> * Tests for BITINT_MAXWIDTH in .  Test that it's defined for 
> C2x, but not defined for C11/C17 (the latter independent of whether the 
> target has _BitInt support).  Test the value as well: _BitInt 
> (BITINT_MAXWIDTH) should be OK (both signed and unsigned) but _BitInt 
> (BITINT_MAXWIDTH + 1) should not be OK.  Also test that BITINT_MAXWIDTH >= 
> ULLONG_MAX.
> 
> * Test _BitInt (N) where N is a constexpr variable or enum constant (I 
> expect these should work - the required call to convert_lvalue_to_rvalue 
> for constexpr to work is present - but I don't see such tests in the 
> testsuite).
> 
> * Test that -funsigned-bitfields does not affect the signedness of _BitInt 
> (N) bit-fields (the standard wording isn't entirely clear, but that's 
> what's implemented in the patches).
> 
> * Test the errors for _Sat used with _BitInt (though such a test might not 
> actually run at present because no target supports both features).

Here is a patch which adds that test coverage.

> I looked at places in c-family/ and c/ that refer to INTEGER_TYPE to 
> consider whether they should handle BITINT_TYPE and whether that matches 
> what the patch does there.  I think the following places that don't handle 
> it probably should (with appropriate testcases added for the relevant 
> functionality, e.g. warnings) unless there is some specific reason in each 
> case why that's unnecessary or incorrect.  c-pretty-print.cc: 
> c_pretty_printer::direct_declarator and c_pretty_printer::declarator.  
> c-warn.cc throughout.  Maybe c-ada-spec.cc, though it might be best to ask 
> the Ada maintainers there.  c-common.cc: unsafe_conversion_p, 
> c_common_truthvalue_conversion warnings, c_common_get_alias_set, 
> check_builtin_function_arguments BUILT_IN_ASSUME_ALIGNED case.  
> c-aux-info.cc (might need other support for generating appropriate names 
> in output).  c-parser.cc:c_parser_omp_clause_schedule.  c-fold.cc 
> throughout.  c-typeck.c: the build_conditional_expr case where one operand 
> is EXCESS_PRECISION_EXPR; build_c_cast; convert_for_assignment checks for 
> integer/pointer conversions.

As well as what I've managed to come up for the above changes.

2023-09-06  Jakub Jelinek  

PR c/102989
* gcc.dg/bitint-2.c (foo): Add tests for constexpr var or enumerator
arguments of _BitInt.
* gcc.dg/bitint-31.c: Remove forgotten 0 &&.
* gcc.dg/bitint-32.c: New test.
* gcc.dg/bitint-33.c: New test.
* gcc.dg/bitint-34.c: New test.
* gcc.dg/bitint-35.c: New test.
* gcc.dg/bitint-36.c: New test.
* gcc.dg/fixed-point/bitint-1.c: New test.

--- gcc/testsuite/gcc.dg/bitint-2.c.jj  2023-09-06 10:57:48.771535739 +0200
+++ gcc/testsuite/gcc.dg/bitint-2.c 2023-09-06 12:17:39.764073758 +0200
@@ -14,6 +14,10 @@ foo (void)
   _BitInt(5) unsigned d = (unsigned _BitInt(5)) 4;
   _BitInt(32) e = (_BitInt(32)) 5;
   _BitInt(32) unsigned f = (unsigned _BitInt(32)) 6;
+  constexpr int g = 43;
+  enum E { F = 44 };
+  _BitInt(g) h;
+  unsigned _BitInt(F) i;
   static_assert (expr_has_type (a, signed _BitInt(42)), "");
   static_assert (expr_has_type (a, _BitInt(42)), "");
   static_assert (!expr_has_type (a, unsigned _BitInt(42)), "");
@@ -66,6 +70,8 @@ foo (void)
   static_assert (expr_has_type (-1UWB, unsigned _BitInt(1)), "");
   static_assert (expr_has_type (1uWB, unsigned _BitInt(1)), "");
   static_assert (expr_has_type (2Uwb, unsigned _BitInt(2)), "");
+  static_assert (expr_has_type (h, signed _BitInt(43)), "");
+  static_assert (expr_has_type (i, unsigned _BitInt(44)), "");
   static_assert (0wb == 0, "");
   static_assert (-1wb == -1, "");
   static_assert (0xwb == 4294967295wb, "");
--- gcc/testsuite/gcc.dg/bitint-31.c.jj 2023-09-06 10:57:48.799535349 +0200
+++ gcc/testsuite/gcc.dg/bitint-31.c2023-09-06 11:52:57.675594550 +0200
@@ -255,7 +255,7 @@ main ()
   check_round (testfltu_192 (340282356779733661637539395458142568448uwb), 
__builtin_inff (), 0xffp+104f, __builtin_inff (), 0xffp+104f);
   check_round (testfltu_192 
(627710173538668076383578942320766641610235564034512895uwb), __builtin_inff 
(), 0xffp+104f, __builtin_inff (), 0xffp+104f);
 #endif
-#if 0 && __BITINT_MAXWIDTH__ >= 575
+#if __BITINT_MAXWIDTH__ >= 575
   check_round (testflt_575 (10633823015541376812058405359715352575wb), 
0xfep+99f, 0xfep+99f, 0xffp+99f, 0xfep+99f);
   check_round (testflt_575 (10633823015541376812058405359715352576wb), 
0xfep+99f, 0xfep+99f, 0xffp+99f, 0xfep+99f);
   check_round (testflt_575 (10633823015541376812058405359715352577wb), 
0xffp+99f, 0xfep+99f, 0xffp+99f, 0xfep+99f);
--- gcc/testsuite/gcc.dg/bitint-32.c.jj 2023-09-06 11:57:24.391907466 +0200
+++ gcc/testsuite/gcc.dg/bitint-32.c2023-09-06 12:00:04.885688154 

[PATCH v2 1/2] riscv: Add support for strlen inline expansion

2023-09-06 Thread Christoph Muellner
From: Christoph Müllner 

This patch implements the expansion of the strlen builtin for RV32/RV64
for xlen-aligned aligned strings if Zbb or XTheadBb instructions are available.
The inserted sequences are:

rv32gc_zbb (RV64 is similar):
  add a3,a0,4
  li  a4,-1
.L1:  lw  a5,0(a0)
  add a0,a0,4
  orc.b   a5,a5
  beq a5,a4,.L1
  not a5,a5
  ctz a5,a5
  srl a5,a5,0x3
  add a0,a0,a5
  sub a0,a0,a3

rv64gc_xtheadbb (RV32 is similar):
  add   a4,a0,8
.L2:  lda5,0(a0)
  add   a0,a0,8
  th.tstnbz a5,a5
  beqz  a5,.L2
  th.reva5,a5
  th.ff1a5,a5
  srl   a5,a5,0x3
  add   a0,a0,a5
  sub   a0,a0,a4

This allows to inline calls to strlen(), with optimized code for
xlen-aligned strings, resulting in the following benefits over
a call to libc:
* no call/ret instructions
* no stack frame allocation
* no register saving/restoring
* no alignment test

The inlining mechanism is gated by a new switch ('-minline-strlen')
and by the variable 'optimize_size'.

Tested using the glibc string tests.

Signed-off-by: Christoph Müllner 

gcc/ChangeLog:

* config.gcc: Add new object riscv-string.o.
riscv-string.cc.
* config/riscv/riscv-protos.h (riscv_expand_strlen):
New function.
* config/riscv/riscv.md (strlen): New expand INSN.
* config/riscv/riscv.opt: New flag 'minline-strlen'.
* config/riscv/t-riscv: Add new object riscv-string.o.
* config/riscv/thead.md (th_rev2): Export INSN name.
(th_rev2): Likewise.
(th_tstnbz2): New INSN.
* doc/invoke.texi: Document '-minline-strlen'.
* emit-rtl.cc (emit_likely_jump_insn): New helper function.
(emit_unlikely_jump_insn): Likewise.
* rtl.h (emit_likely_jump_insn): New prototype.
(emit_unlikely_jump_insn): Likewise.
* config/riscv/riscv-string.cc: New file.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/xtheadbb-strlen-unaligned.c: New test.
* gcc.target/riscv/xtheadbb-strlen.c: New test.
* gcc.target/riscv/zbb-strlen-disabled-2.c: New test.
* gcc.target/riscv/zbb-strlen-disabled.c: New test.
* gcc.target/riscv/zbb-strlen-unaligned.c: New test.
* gcc.target/riscv/zbb-strlen.c: New test.
---
 gcc/config.gcc|   3 +-
 gcc/config/riscv/riscv-protos.h   |   3 +
 gcc/config/riscv/riscv-string.cc  | 183 ++
 gcc/config/riscv/riscv.md |  28 +++
 gcc/config/riscv/riscv.opt|   4 +
 gcc/config/riscv/t-riscv  |   6 +
 gcc/config/riscv/thead.md |   9 +-
 gcc/doc/invoke.texi   |  11 +-
 gcc/emit-rtl.cc   |  24 +++
 gcc/rtl.h |   2 +
 .../riscv/xtheadbb-strlen-unaligned.c |  14 ++
 .../gcc.target/riscv/xtheadbb-strlen.c|  19 ++
 .../gcc.target/riscv/zbb-strlen-disabled-2.c  |  15 ++
 .../gcc.target/riscv/zbb-strlen-disabled.c|  15 ++
 .../gcc.target/riscv/zbb-strlen-unaligned.c   |  14 ++
 gcc/testsuite/gcc.target/riscv/zbb-strlen.c   |  19 ++
 16 files changed, 366 insertions(+), 3 deletions(-)
 create mode 100644 gcc/config/riscv/riscv-string.cc
 create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadbb-strlen-unaligned.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadbb-strlen.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen-disabled-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen-disabled.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen-unaligned.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen.c

diff --git a/gcc/config.gcc b/gcc/config.gcc
index b2fe7c7ceef..aff6b6a5601 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -530,7 +530,8 @@ pru-*-*)
;;
 riscv*)
cpu_type=riscv
-   extra_objs="riscv-builtins.o riscv-c.o riscv-sr.o 
riscv-shorten-memrefs.o riscv-selftests.o riscv-v.o riscv-vsetvl.o 
riscv-vector-costs.o"
+   extra_objs="riscv-builtins.o riscv-c.o riscv-sr.o 
riscv-shorten-memrefs.o riscv-selftests.o riscv-string.o"
+   extra_objs="${extra_objs} riscv-v.o riscv-vsetvl.o riscv-vector-costs.o"
extra_objs="${extra_objs} riscv-vector-builtins.o 
riscv-vector-builtins-shapes.o riscv-vector-builtins-bases.o"
extra_objs="${extra_objs} thead.o"
d_target_objs="riscv-d.o"
diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index 6dbf6b9f943..b060d047f01 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-protos.h
@@ -517,6 +517,9 @@ const unsigned int RISCV_BUILTIN_SHIFT = 1;
 /* Mask that selects the riscv_builtin_class part of a function code.  */
 const unsigned int RISCV_BUILTIN_CLASS = (1 << RISCV_BUILTIN_SHIFT) - 1;
 
+/* Routines implemented 

[PATCH v2 2/2] riscv: Add support for str(n)cmp inline expansion

2023-09-06 Thread Christoph Muellner
From: Christoph Müllner 

This patch implements expansions for the cmpstrsi and cmpstrnsi
builtins for RV32/RV64 for xlen-aligned strings if Zbb or XTheadBb
instructions are available.  The expansion basically emits a comparison
sequence which compares XLEN bits per step if possible.

This allows to inline calls to strcmp() and strncmp() if both strings
are xlen-aligned.  For strncmp() the length parameter needs to be known.
The benefits over calls to libc are:
* no call/ret instructions
* no stack frame allocation
* no register saving/restoring
* no alignment tests

The inlining mechanism is gated by a new switches ('-minline-strcmp' and
'-minline-strncmp') and by the variable 'optimize_size'.
The amount of emitted unrolled loop iterations can be controlled by the
parameter '--param=riscv-strcmp-inline-limit=N', which defaults to 64.

The comparision sequence is inspired by the strcmp example
in the appendix of the Bitmanip specification (incl. the fast
result calculation in case the first word does not contain
a NULL byte).  Additional inspiration comes from rs6000-string.c.

The emitted sequence is not triggering any readahead pagefault issues,
because only aligned strings are accessed by aligned xlen-loads.

This patch has been tested using the glibc string tests on QEMU:
* rv64gc_zbb/rv64gc_xtheadbb with riscv-strcmp-inline-limit=64
* rv64gc_zbb/rv64gc_xtheadbb with riscv-strcmp-inline-limit=8
* rv32gc_zbb/rv32gc_xtheadbb with riscv-strcmp-inline-limit=64

Signed-off-by: Christoph Müllner 

gcc/ChangeLog:

* config/riscv/bitmanip.md (*_not): Export INSN name.
(_not3): Likewise.
* config/riscv/riscv-protos.h (riscv_expand_strcmp): New
prototype.
* config/riscv/riscv-string.cc (GEN_EMIT_HELPER3): New helper
macros.
(GEN_EMIT_HELPER2): Likewise.
(emit_strcmp_scalar_compare_byte): New function.
(emit_strcmp_scalar_compare_subword): Likewise.
(emit_strcmp_scalar_compare_word): Likewise.
(emit_strcmp_scalar_load_and_compare): Likewise.
(emit_strcmp_scalar_call_to_libc): Likewise.
(emit_strcmp_scalar_result_calculation_nonul): Likewise.
(emit_strcmp_scalar_result_calculation): Likewise.
(riscv_expand_strcmp_scalar): Likewise.
(riscv_expand_strcmp): Likewise.
* config/riscv/riscv.md (*slt_): Export
INSN name.
(@slt_3): Likewise.
(cmpstrnsi): Invoke expansion function for str(n)cmp.
(cmpstrsi): Likewise.
* config/riscv/riscv.opt: Add new parameter
'-mstring-compare-inline-limit'.
* doc/invoke.texi: Document new parameter
'-mstring-compare-inline-limit'.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/xtheadbb-strcmp-unaligned.c: New test.
* gcc.target/riscv/xtheadbb-strcmp.c: New test.
* gcc.target/riscv/zbb-strcmp-disabled-2.c: New test.
* gcc.target/riscv/zbb-strcmp-disabled.c: New test.
* gcc.target/riscv/zbb-strcmp-unaligned.c: New test.
* gcc.target/riscv/zbb-strcmp.c: New test.
---
 gcc/config/riscv/bitmanip.md  |   2 +-
 gcc/config/riscv/riscv-protos.h   |   1 +
 gcc/config/riscv/riscv-string.cc  | 411 ++
 gcc/config/riscv/riscv.md |  44 +-
 gcc/config/riscv/riscv.opt|  12 +
 gcc/doc/invoke.texi   |  20 +-
 .../gcc.target/riscv/xtheadbb-strcmp.c|  57 +++
 .../gcc.target/riscv/zbb-strcmp-disabled-2.c  |  38 ++
 .../gcc.target/riscv/zbb-strcmp-disabled.c|  38 ++
 .../gcc.target/riscv/zbb-strcmp-limit.c   |  57 +++
 .../gcc.target/riscv/zbb-strcmp-unaligned.c   |  38 ++
 gcc/testsuite/gcc.target/riscv/zbb-strcmp.c   |  57 +++
 12 files changed, 772 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadbb-strcmp.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp-disabled-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp-disabled.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp-limit.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp-unaligned.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp.c

diff --git a/gcc/config/riscv/bitmanip.md b/gcc/config/riscv/bitmanip.md
index 1544ef4e125..1e90636dd60 100644
--- a/gcc/config/riscv/bitmanip.md
+++ b/gcc/config/riscv/bitmanip.md
@@ -206,7 +206,7 @@ (define_expand "popcount2"
(popcount:GPR (match_operand:GPR 1 "register_operand")))]
   "TARGET_ZBB")
 
-(define_insn "*_not"
+(define_insn "_not3"
   [(set (match_operand:X 0 "register_operand" "=r")
 (bitmanip_bitwise:X (not:X (match_operand:X 1 "register_operand" "r"))
 (match_operand:X 2 "register_operand" "r")))]
diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index b060d047f01..0006fe0564e 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ 

[PATCH v2 0/2] riscv: Introduce strlen/strcmp/strncmp inline expansion

2023-09-06 Thread Christoph Muellner
From: Christoph Müllner 

This series introduces strlen/strcmp/strncmp inline expansion for Zbb/XTheadBb.

In the last months, glibc as well as the Linux kernel merged changes for
optimized string processing for RISC-V. The instruction, which enables
optimized string routines is Zbb's orc.b (or T-Head's th.tstnbz) instruction.

This patch attempts to add optimized string processing to GCC with the
following properties:
* strlen: inline a loop if the string is xlen-aligned
* strcmp/strncmp: inline a peeled comparison loop sequence if both strings
  are xlen-aligned

I've already posted the idea in a previous series last November
(therefore, this series is called 'v2'):
* https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605996.html
* https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605998.html

Back then, there were a couple of comments, which have been addressed,
but the str(n)cmp patch has been restructured to make the code easier
to digest.  In total the following changes are made:
* Address Jeff's comments for the strlen patch
* Change str(n)cmp flags according to Kito's comments
* Ensure that all flags are documented
* Break str(n)cmp expansion into several functions
* Add support for XTheadBb's th.tstnbz

I have not introduced "-minline-str[n]cmp=[bitmanip|vector|auto]"
or "-mstringop-strategy=alg" because we only have one bitmanip/scalar
expansion.  But it is possible to add this in the future (or not and
decide based on mtune).

By default all optimizations are disabled, so there should be no risk
of regressions.

Testing was done using the following strategy:
* Enablement/flag tests are part of the patches
* Correctness was tested using qemu-user with glibc's string tests compiled for:
** rv64gc (baseline) QEMU_CPU=rv64
** rv64gc_zbb (limit=64) QEMU_CPU=rv64,zbb=false (must fail)
** rv64gc_zbb (limit=64) QEMU_CPU=rv64,zbb=true
** rv64gc_zbb (limit=32) QEMU_CPU=rv64,zbb=true
** rv64gc_xtheadbb (limit=64) QEMU_CPU=rv64 (must fail)
** rv64gc_xtheadbb (limit=64) QEMU_CPU=thead-c906
** rv64gc_xtheadbb (limit=8) QEMU_CPU=thead-c906
** rv32gc_zbb (limit=64) QEMU_CPU=rv32,zbb=true
* SPEC CPU 2017 intrate base/peak with LTO

Christoph Müllner (2):
  riscv: Add support for strlen inline expansion
  riscv: Add support for str(n)cmp inline expansion

 gcc/config.gcc|   3 +-
 gcc/config/riscv/bitmanip.md  |   2 +-
 gcc/config/riscv/riscv-protos.h   |   4 +
 gcc/config/riscv/riscv-string.cc  | 594 ++
 gcc/config/riscv/riscv.md |  72 ++-
 gcc/config/riscv/riscv.opt|  16 +
 gcc/config/riscv/t-riscv  |   6 +
 gcc/config/riscv/thead.md |   9 +-
 gcc/doc/invoke.texi   |  29 +-
 gcc/emit-rtl.cc   |  24 +
 gcc/rtl.h |   2 +
 .../gcc.target/riscv/xtheadbb-strcmp.c|  57 ++
 .../riscv/xtheadbb-strlen-unaligned.c |  14 +
 .../gcc.target/riscv/xtheadbb-strlen.c|  19 +
 .../gcc.target/riscv/zbb-strcmp-disabled-2.c  |  38 ++
 .../gcc.target/riscv/zbb-strcmp-disabled.c|  38 ++
 .../gcc.target/riscv/zbb-strcmp-limit.c   |  57 ++
 .../gcc.target/riscv/zbb-strcmp-unaligned.c   |  38 ++
 gcc/testsuite/gcc.target/riscv/zbb-strcmp.c   |  57 ++
 .../gcc.target/riscv/zbb-strlen-disabled-2.c  |  15 +
 .../gcc.target/riscv/zbb-strlen-disabled.c|  15 +
 .../gcc.target/riscv/zbb-strlen-unaligned.c   |  14 +
 gcc/testsuite/gcc.target/riscv/zbb-strlen.c   |  19 +
 23 files changed, 1137 insertions(+), 5 deletions(-)
 create mode 100644 gcc/config/riscv/riscv-string.cc
 create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadbb-strcmp.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadbb-strlen-unaligned.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadbb-strlen.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp-disabled-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp-disabled.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp-limit.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp-unaligned.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen-disabled-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen-disabled.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen-unaligned.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen.c

-- 
2.41.0



[committed 10/12 v2] C _BitInt support [PR102989]

2023-09-06 Thread Jakub Jelinek via Gcc-patches
Hi!

Thanks for the patch reviews (and to Richi and Uros as well) and everyone
who participated in discussions.

Here is the updated version of the C _BitInt support [PR102989] patch
I've committed to trunk in addition to the rest of the series (except the
_BitInt a ? ~b : b match.pd fix patch, which will need to be resolved
eventually).

On Tue, Sep 05, 2023 at 10:40:26PM +, Joseph Myers wrote:
> Maybe c-ada-spec.cc, though it might be best to ask 
> the Ada maintainers there.

I've skipped c-ada-spec.cc and will file a PR for Ada maintainers,
it is up to them to decide what they want and how to implement that.

2023-09-06  Jakub Jelinek  

PR c/102989
gcc/
* glimits.h (BITINT_MAXWIDTH): Define if __BITINT_MAXWIDTH__ is
predefined.
gcc/c-family/
* c-common.cc (c_common_reswords): Add _BitInt as keyword.
(unsafe_conversion_p): Handle BITINT_TYPE like INTEGER_TYPE.
(c_common_signed_or_unsigned_type): Handle BITINT_TYPE.
(c_common_truthvalue_conversion, c_common_get_alias_set,
check_builtin_function_arguments): Handle BITINT_TYPE like
INTEGER_TYPE.
(sync_resolve_size): Add ORIG_FORMAT argument.  If
FETCH && !ORIG_FORMAT, type is BITINT_TYPE, return -1 if size isn't
one of 1, 2, 4, 8 or 16 or if it is 16 but TImode is not supported.
(atomic_bitint_fetch_using_cas_loop): New function.
(resolve_overloaded_builtin): Adjust sync_resolve_size caller.  If
-1 is returned, use atomic_bitint_fetch_using_cas_loop to lower it.
Formatting fix.
(keyword_begins_type_specifier): Handle RID_BITINT.
* c-common.h (enum rid): Add RID_BITINT enumerator.
* c-cppbuiltin.cc (c_cpp_builtins): For C call
targetm.c.bitint_type_info and predefine __BITINT_MAXWIDTH__
and for -fbuilding-libgcc also __LIBGCC_BITINT_LIMB_WIDTH__ and
__LIBGCC_BITINT_ORDER__ macros if _BitInt is supported.
* c-lex.cc (interpret_integer): Handle CPP_N_BITINT.
* c-pretty-print.cc (c_pretty_printer::simple_type_specifier,
c_pretty_printer::direct_abstract_declarator,
c_pretty_printer::direct_declarator, c_pretty_printer::declarator):
Handle BITINT_TYPE.
(pp_c_integer_constant): Handle printing of large precision wide_ints
which would buffer overflow digit_buffer.
* c-warn.cc (conversion_warning, warnings_for_convert_and_check,
warnings_for_convert_and_check): Handle BITINT_TYPE like
INTEGER_TYPE.
gcc/c/
* c-convert.cc (c_convert): Handle BITINT_TYPE like INTEGER_TYPE.
* c-decl.cc (check_bitfield_type_and_width): Allow BITINT_TYPE
bit-fields.
(finish_struct): Prefer to use BITINT_TYPE for BITINT_TYPE bit-fields
if possible.
(declspecs_add_type): Formatting fixes.  Handle cts_bitint.  Adjust
for added union in *specs.  Handle RID_BITINT.
(finish_declspecs): Handle cts_bitint.  Adjust for added union
in *specs.
* c-parser.cc (c_keyword_starts_typename, c_token_starts_declspecs,
c_parser_declspecs, c_parser_gnu_attribute_any_word): Handle
RID_BITINT.
(c_parser_omp_clause_schedule): Handle BITINT_TYPE like INTEGER_TYPE.
* c-tree.h (enum c_typespec_keyword): Mention _BitInt in comment.
Add cts_bitint enumerator.
(struct c_declspecs): Move int_n_idx and floatn_nx_idx into a union
and add bitint_prec there as well.
* c-typeck.cc (c_common_type, comptypes_internal):
Handle BITINT_TYPE.
(perform_integral_promotions): Promote BITINT_TYPE bit-fields to
their declared type.
(build_array_ref, build_unary_op, build_conditional_expr,
build_c_cast, convert_for_assignment, digest_init, build_binary_op):
Handle BITINT_TYPE.
* c-fold.cc (c_fully_fold_internal): Handle BITINT_TYPE like
INTEGER_TYPE.
* c-aux-info.cc (gen_type): Handle BITINT_TYPE.
libcpp/
* expr.cc (interpret_int_suffix): Handle wb and WB suffixes.
* include/cpplib.h (CPP_N_BITINT): Define.

--- gcc/glimits.h.jj2023-09-05 16:44:32.269305435 +0200
+++ gcc/glimits.h   2023-09-06 09:14:53.950335938 +0200
@@ -157,6 +157,11 @@ see the files COPYING3 and COPYING.RUNTI
 # undef BOOL_WIDTH
 # define BOOL_WIDTH 1
 
+# ifdef __BITINT_MAXWIDTH__
+#  undef BITINT_MAXWIDTH
+#  define BITINT_MAXWIDTH __BITINT_MAXWIDTH__
+# endif
+
 # define __STDC_VERSION_LIMITS_H__ 202311L
 #endif
 
--- gcc/c-family/c-common.cc.jj 2023-09-05 16:44:32.110307593 +0200
+++ gcc/c-family/c-common.cc2023-09-06 09:55:30.836992346 +0200
@@ -349,6 +349,7 @@ const struct c_common_resword c_common_r
   { "_Alignas",RID_ALIGNAS,   D_CONLY },
   { "_Alignof",RID_ALIGNOF,   D_CONLY },
   { "_Atomic", RID_ATOMIC,D_CONLY },
+  { "_BitInt", RID_BITINT,D_CONLY },
   { "_Bool",   RID_BOOL,  D_CONLY 

Re: [PATCH] core: Support heap-based trampolines

2023-09-06 Thread FX Coudert via Gcc-patches
Hi,

ping**2 on the revised patch, for Richard or another global reviewer. So far 
all review feedback is that it’s a step forward, and it’s been widely used for 
both aarch64-darwin and x86_64-darwin distributions for almost three years now.

OK to commit?
FX



> Le 5 août 2023 à 16:20, FX Coudert  a écrit :
> 
> Hi Richard,
> 
> Thanks for your feedback. Here is an amended version of the patch, taking 
> into consideration your requests and the following discussion. There is no 
> configure option for the libgcc part, and the documentation is amended. The 
> patch is split into three commits for core, target and libgcc.
> 
> Currently regtesting on x86_64 linux and darwin (it was fine before I split 
> up into three commits, so I’m re-testing to make sure I didn’t screw anything 
> up).
> 
> OK to commit?
> FX



0001-core-Support-heap-based-trampolines.patch
Description: Binary data


0002-target-Support-heap-based-trampolines.patch
Description: Binary data


0003-libgcc-support-heap-based-trampolines.patch
Description: Binary data


[Committed V2] RISC-V: Fix incorrect mode tieable which cause ICE in RA[PR111296]

2023-09-06 Thread Juzhe-Zhong
This patch fix incorrect mode tieable between DI and V2SI which cause ICE
in RA.

PR target/111296

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_modes_tieable_p): Fix incorrect mode 
tieable for RVV modes.

gcc/testsuite/ChangeLog:

* g++.target/riscv/rvv/base/pr111296.C: New test.

---
 gcc/config/riscv/riscv.cc  |  5 +
 .../g++.target/riscv/rvv/base/pr111296.C   | 18 ++
 2 files changed, 23 insertions(+)
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/pr111296.C

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 228515acc1f..a3d3389e7e2 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -7648,6 +7648,11 @@ riscv_hard_regno_mode_ok (unsigned int regno, 
machine_mode mode)
 static bool
 riscv_modes_tieable_p (machine_mode mode1, machine_mode mode2)
 {
+  /* We don't allow different REG_CLASS modes tieable since it
+ will cause ICE in register allocation (RA).
+ E.g. V2SI and DI are not tieable.  */
+  if (riscv_v_ext_mode_p (mode1) != riscv_v_ext_mode_p (mode2))
+return false;
   return (mode1 == mode2
  || !(GET_MODE_CLASS (mode1) == MODE_FLOAT
   && GET_MODE_CLASS (mode2) == MODE_FLOAT));
diff --git a/gcc/testsuite/g++.target/riscv/rvv/base/pr111296.C 
b/gcc/testsuite/g++.target/riscv/rvv/base/pr111296.C
new file mode 100644
index 000..6eb14fd83a8
--- /dev/null
+++ b/gcc/testsuite/g++.target/riscv/rvv/base/pr111296.C
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-std=c++03 -march=rv64gcv -mabi=lp64d -Ofast -ftree-vectorize 
--param=riscv-autovec-preference=scalable" } */
+
+struct a
+{
+  int b;
+  int c;
+};
+int d;
+a
+e ()
+{
+  a f;
+  int g = d - 1, h = d / 2 - 1;
+  f.b = g;
+  f.c = h;
+  return f;
+}
-- 
2.36.3



Re: [PATCH 1/2] diagnostics: add error_meta

2023-09-06 Thread Arthur Cohen

On 9/6/23 16:12, David Malcolm wrote:

On Wed, 2023-09-06 at 15:53 +0200, Arthur Cohen wrote:

From: David Malcolm 


I guess I can review this patch :)

Needs a ChangeLog entry, so here's one:

gcc/ChangeLog
* diagnostic-core.h (error_meta): New decl.
* diagnostic.cc (error_meta): New.

Also, needs a signed-off-by, so here's one:

Signed-off-by: David Malcolm 



Right! Now that we enforce Changelogs and SoB lines in our CI, I 
completely forgot to add them back to older commits. I'll fix the second 
commit too. Thanks for the fast review!




OK for trunk with those added.

Thanks
Dave





---
  gcc/diagnostic-core.h |  3 +++
  gcc/diagnostic.cc | 15 +++
  2 files changed, 18 insertions(+)

diff --git a/gcc/diagnostic-core.h b/gcc/diagnostic-core.h
index 7334c79e8e6..c9e27fd2e6e 100644
--- a/gcc/diagnostic-core.h
+++ b/gcc/diagnostic-core.h
@@ -92,6 +92,9 @@ extern void error_n (location_t, unsigned
HOST_WIDE_INT, const char *,
  extern void error_at (location_t, const char *, ...)
ATTRIBUTE_GCC_DIAG(2,3);
  extern void error_at (rich_location *, const char *, ...)
    ATTRIBUTE_GCC_DIAG(2,3);
+extern void error_meta (rich_location *, const diagnostic_metadata
&,
+   const char *, ...)
+  ATTRIBUTE_GCC_DIAG(3,4);
  extern void fatal_error (location_t, const char *, ...)
ATTRIBUTE_GCC_DIAG(2,3)
   ATTRIBUTE_NORETURN;
  /* Pass one of the OPT_W* from options.h as the second parameter.
*/
diff --git a/gcc/diagnostic.cc b/gcc/diagnostic.cc
index c523f215bae..65c0cfbf11a 100644
--- a/gcc/diagnostic.cc
+++ b/gcc/diagnostic.cc
@@ -2108,6 +2108,21 @@ error_at (rich_location *richloc, const char
*gmsgid, ...)
    va_end (ap);
  }
  
+/* Same as above, but with metadata.  */

+
+void
+error_meta (rich_location *richloc, const diagnostic_metadata
,
+   const char *gmsgid, ...)
+{
+  gcc_assert (richloc);
+
+  auto_diagnostic_group d;
+  va_list ap;
+  va_start (ap, gmsgid);
+  diagnostic_impl (richloc, , -1, gmsgid, , DK_ERROR);
+  va_end (ap);
+}
+
  /* "Sorry, not implemented."  Use for a language feature which is
     required by the relevant specification but not implemented by
GCC.
     An object file will not be produced.  */




Re: [PATCH 2/2] Experiment with adding an error code to an error

2023-09-06 Thread David Malcolm via Gcc-patches
On Wed, 2023-09-06 at 15:53 +0200, Arthur Cohen wrote:
> From: David Malcolm 

This is probably something for the gcc-rust maintainers to review
(rather than me self-reviewing with my "diagnostics maintainer" hat
on).

Doesn't have a ChangeLog entry, FWIW.
Doesn't have a signed-off-by, so here's one:

Signed-off-by: David Malcolm 

[...snip...]

> diff --git a/gcc/rust/rust-gcc-diagnostics.cc b/gcc/rust/rust-gcc-
> diagnostics.cc
> index 72d2c068541..58c0a5654ea 100644
> --- a/gcc/rust/rust-gcc-diagnostics.cc
> +++ b/gcc/rust/rust-gcc-diagnostics.cc

[...snip...]

> +void
> +rust_be_error_at (const RichLocation , const ErrorCode
> code,
> + const std::string )
> +{
> +  /* TODO: 'error_at' would like a non-'const' 'rich_location *'. 

The above comment should refer to "error_meta", rather than
"error_at"...

> */
> +  rich_location _loc = const_cast (location.get
> ());
> +  diagnostic_metadata m;
> +  rust_error_code_rule rule (code);
> +  m.add_rule (rule);
> +  error_meta (_loc, m, "%s", errmsg.c_str ());

... to match this call.

[...snip...]

Otherwise, LGTM, but as I said, this is more in the gcc-rust
maintainers' area.

Dave



Re: [PATCH 1/2] diagnostics: add error_meta

2023-09-06 Thread David Malcolm via Gcc-patches
On Wed, 2023-09-06 at 15:53 +0200, Arthur Cohen wrote:
> From: David Malcolm 

I guess I can review this patch :)

Needs a ChangeLog entry, so here's one:

gcc/ChangeLog
* diagnostic-core.h (error_meta): New decl.
* diagnostic.cc (error_meta): New.

Also, needs a signed-off-by, so here's one:

Signed-off-by: David Malcolm 


OK for trunk with those added.

Thanks
Dave



> 
> ---
>  gcc/diagnostic-core.h |  3 +++
>  gcc/diagnostic.cc | 15 +++
>  2 files changed, 18 insertions(+)
> 
> diff --git a/gcc/diagnostic-core.h b/gcc/diagnostic-core.h
> index 7334c79e8e6..c9e27fd2e6e 100644
> --- a/gcc/diagnostic-core.h
> +++ b/gcc/diagnostic-core.h
> @@ -92,6 +92,9 @@ extern void error_n (location_t, unsigned
> HOST_WIDE_INT, const char *,
>  extern void error_at (location_t, const char *, ...)
> ATTRIBUTE_GCC_DIAG(2,3);
>  extern void error_at (rich_location *, const char *, ...)
>    ATTRIBUTE_GCC_DIAG(2,3);
> +extern void error_meta (rich_location *, const diagnostic_metadata
> &,
> +   const char *, ...)
> +  ATTRIBUTE_GCC_DIAG(3,4);
>  extern void fatal_error (location_t, const char *, ...)
> ATTRIBUTE_GCC_DIAG(2,3)
>   ATTRIBUTE_NORETURN;
>  /* Pass one of the OPT_W* from options.h as the second parameter. 
> */
> diff --git a/gcc/diagnostic.cc b/gcc/diagnostic.cc
> index c523f215bae..65c0cfbf11a 100644
> --- a/gcc/diagnostic.cc
> +++ b/gcc/diagnostic.cc
> @@ -2108,6 +2108,21 @@ error_at (rich_location *richloc, const char
> *gmsgid, ...)
>    va_end (ap);
>  }
>  
> +/* Same as above, but with metadata.  */
> +
> +void
> +error_meta (rich_location *richloc, const diagnostic_metadata
> ,
> +   const char *gmsgid, ...)
> +{
> +  gcc_assert (richloc);
> +
> +  auto_diagnostic_group d;
> +  va_list ap;
> +  va_start (ap, gmsgid);
> +  diagnostic_impl (richloc, , -1, gmsgid, , DK_ERROR);
> +  va_end (ap);
> +}
> +
>  /* "Sorry, not implemented."  Use for a language feature which is
>     required by the relevant specification but not implemented by
> GCC.
>     An object file will not be produced.  */



Re: [PATCH v4 1/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

2023-09-06 Thread Jeff Law via Gcc-patches




On 9/5/23 23:47, Tsukasa OI wrote:

From: Tsukasa OI 

'XVentanaCondOps' is a vendor extension from Ventana Micro Systems
containing two instructions for conditional move and will be supported on
their Veyron V1 CPU.

And most notably (for historical reasons), 'XVentanaCondOps' and the
standard 'Zicond' extension are functionally equivalent (only encodings and
instruction names are different).

*   czero.eqz == vt.maskc
*   czero.nez == vt.maskcn

This commit adds support for the 'XVentanaCondOps' extension by extending
'Zicond' extension support.  With this, we can now reuse the optimization
using the 'Zicond' extension for the 'XVentanaCondOps' extension.

The specification for the 'XVentanaCondOps' extension is based on:


gcc/ChangeLog:

* common/config/riscv/riscv-common.cc (riscv_ext_flag_table):
Parse 'XVentanaCondOps' extension.
* config/riscv/riscv-opts.h (MASK_XVENTANACONDOPS): New.
(TARGET_XVENTANACONDOPS): Ditto.
(TARGET_ZICOND_LIKE): New to represent targets with conditional
moves like 'Zicond'.  It includes RV64 + 'XVentanaCondOps'.
* config/riscv/riscv.cc (riscv_rtx_costs): Replace TARGET_ZICOND
with TARGET_ZICOND_LIKE.
(riscv_expand_conditional_move): Ditto.
* config/riscv/riscv.md (movcc): Replace TARGET_ZICOND with
TARGET_ZICOND_LIKE.
* config/riscv/riscv.opt: Add new riscv_xventana_subext.
* config/riscv/zicond.md: Modify description.
(eqz_ventana): New to match corresponding czero instructions.
(nez_ventana): Ditto.
(*czero..): Emit a 'XVentanaCondOps' instruction if
'Zicond' is not available but 'XVentanaCondOps' + RV64 is.
(*czero..): Ditto.
(*czero.eqz..opt1): Ditto.
(*czero.nez..opt2): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/xventanacondops-primitiveSemantics.c: New test,
* gcc.target/riscv/xventanacondops-primitiveSemantics-rv32.c: New
test to make sure that XVentanaCondOps instructions are disabled
on RV32.
* gcc.target/riscv/xventanacondops-xor-01.c: New test,
OK.  Thanks for taking care of this.  I guess Raphael and I should get 
more active on pushing the rest of the veyron-v1 bits upstream :-)


Jeff


Re: [PATCH] RISC-V: Fix incorrect mode tieable which cause ICE in RA[PR111296]

2023-09-06 Thread Jeff Law via Gcc-patches




On 9/6/23 03:47, Juzhe-Zhong wrote:

This patch fix incorrect mode tieable between DI and V2SI which cause ICE
in RA.

PR target/111296

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_modes_tieable_p): Fix bug.

gcc/testsuite/ChangeLog:

* g++.target/riscv/rvv/base/pr111296.C: New test.




---
  gcc/config/riscv/riscv.cc  |  7 +++
  .../g++.target/riscv/rvv/base/pr111296.C   | 18 ++
  2 files changed, 25 insertions(+)
  create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/pr111296.C

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 228515acc1f..2c0c4c2f3ae 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -7648,6 +7648,13 @@ riscv_hard_regno_mode_ok (unsigned int regno, 
machine_mode mode)
  static bool
  riscv_modes_tieable_p (machine_mode mode1, machine_mode mode2)
  {
+  /* We don't allow different REG_CLASS modes tieable since it
+ will cause ICE in register allocation (RA).
+ E.g. V2SI and DI are not tieable.  */
+  if (riscv_v_ext_mode_p (mode1) && !riscv_v_ext_mode_p (mode2))
+return false;
+  else if (riscv_v_ext_mode_p (mode2) && !riscv_v_ext_mode_p (mode1))
+return false;

Isn't this just
if (riscv_v_ext_mode_p (mode1) != riscv_v_ext_mode_p (mode2))

OK with that change.

jeff


RE: [PATCH] RISC-V: Remove unreasonable TARGET_64BIT for VLS modes with size = 64bit

2023-09-06 Thread Li, Pan2 via Gcc-patches
Committed, thanks Robin.

Pan

-Original Message-
From: Gcc-patches  On Behalf 
Of Robin Dapp via Gcc-patches
Sent: Wednesday, September 6, 2023 9:39 PM
To: Juzhe-Zhong ; gcc-patches@gcc.gnu.org
Cc: kito.ch...@sifive.com; kito.ch...@gmail.com
Subject: Re: [PATCH] RISC-V: Remove unreasonable TARGET_64BIT for VLS modes 
with size = 64bit

LGTM.

Regards
 Robin



RE: [PATCH] RISC-V: Fix VSETVL PASS AVL/VL fetch bug[111295]

2023-09-06 Thread Li, Pan2 via Gcc-patches
Committed, thanks Robin.

Pan

-Original Message-
From: Gcc-patches  On Behalf 
Of Robin Dapp via Gcc-patches
Sent: Wednesday, September 6, 2023 9:38 PM
To: Juzhe-Zhong ; gcc-patches@gcc.gnu.org
Cc: kito.ch...@sifive.com; kito.ch...@gmail.com
Subject: Re: [PATCH] RISC-V: Fix VSETVL PASS AVL/VL fetch bug[111295]

OK.

Regards
 Robin


Re: [PATCH] ggc, jit: forcibly clear GTY roots in jit

2023-09-06 Thread Antoni Boucher via Gcc-patches
Hi.
I'll do another test to make sure this is enough since I tested with a
few more finalize functions.
Thanks a lot for finding this!

On Wed, 2023-09-06 at 09:40 -0400, David Malcolm via Jit wrote:
> As part of Antoyo's work on supporting LTO in rustc_codegen_gcc, he
> noticed an ICE inside libgccjit when compiling certain rust files.
> 
> Debugging libgccjit showed that outdated information from a previous
> in-memory compile was referring to ad-hoc locations in the previous
> compile's line_table.
> 
> The issue turned out to be the function decls in
> internal_fn_fnspec_array
> from the previous compile keeping alive the symtab nodes for these
> functions, and from this finding other functions in the previous
> compile, walking their CFGs, and finding ad-hoc data pointers in an
> edge
> with a location_t using ad-hoc data from the previous line_table
> instance, and thus a use-after-free ICE attempting to use this ad-hoc
> data.
> 
> Previously in toplev::finalize we've fixed global state "piecemeal"
> by
> calling out to individual source_name_cc_finalize functions. 
> However,
> it occurred to me that we have run-time information on where the
> GTY-marked pointers are.
> 
> Hence this patch takes something of a "big hammer" approach by adding
> a
> new ggc_common_finalize that walks the GC roots, zeroing all of the
> pointers.  I stepped through this in the debugger and observed that,
> in
> particular, this correctly zeroes the internal_fn_fnspec_array at the
> end
> of a libgccjit compile.  Antoyo reports that this fixes the ICE for
> him.
> Doing so uncovered an ICE with libgccjit in dwarf2cfi.cc due to reuse
> of
> global variables from the previous compile, which this patch also
> fixes.
> 
> I noticed that in ggc_mark_roots when clearing deletable roots we
> only
> clear the initial element in each gcc_root_tab_t.  This looks like a
> latent bug to me, which the patch fixes.  That said, there don't seem
> to
> be any deletable roots where the number of elements != 1.
> 
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> 
> OK for trunk?
> 
> Thanks
> Dave
> 
> gcc/ChangeLog:
> * dwarf2cfi.cc (dwarf2cfi_cc_finalize): New.
> * dwarf2out.h (dwarf2cfi_cc_finalize): New decl.
> * ggc-common.cc (ggc_mark_roots): Multiply by rti->nelt when
> clearing the deletable gcc_root_tab_t.
> (ggc_common_finalize): New.
> * ggc.h (ggc_common_finalize): New decl.
> * toplev.cc (toplev::finalize): Call dwarf2cfi_cc_finalize
> and
>     ggc_common_finalize.
> ---
>  gcc/dwarf2cfi.cc  |  9 +
>  gcc/dwarf2out.h   |  1 +
>  gcc/ggc-common.cc | 23 ++-
>  gcc/ggc.h |  2 ++
>  gcc/toplev.cc |  3 +++
>  5 files changed, 37 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/dwarf2cfi.cc b/gcc/dwarf2cfi.cc
> index ddc728f4ad00..f1777c0a4cf1 100644
> --- a/gcc/dwarf2cfi.cc
> +++ b/gcc/dwarf2cfi.cc
> @@ -3822,4 +3822,13 @@ make_pass_dwarf2_frame (gcc::context *ctxt)
>    return new pass_dwarf2_frame (ctxt);
>  }
>  
> +void dwarf2cfi_cc_finalize ()
> +{
> +  add_cfi_insn = NULL;
> +  add_cfi_vec = NULL;
> +  cur_trace = NULL;
> +  cur_row = NULL;
> +  cur_cfa = NULL;
> +}
> +
>  #include "gt-dwarf2cfi.h"
> diff --git a/gcc/dwarf2out.h b/gcc/dwarf2out.h
> index 870b56a6a372..61a996050ff9 100644
> --- a/gcc/dwarf2out.h
> +++ b/gcc/dwarf2out.h
> @@ -419,6 +419,7 @@ struct fixed_point_type_info
>  } scale_factor;
>  };
>  
> +void dwarf2cfi_cc_finalize (void);
>  void dwarf2out_cc_finalize (void);
>  
>  /* Some DWARF internals are exposed for the needs of DWARF-based
> debug
> diff --git a/gcc/ggc-common.cc b/gcc/ggc-common.cc
> index bed7a9d4d021..95803fa95a17 100644
> --- a/gcc/ggc-common.cc
> +++ b/gcc/ggc-common.cc
> @@ -86,7 +86,7 @@ ggc_mark_roots (void)
>  
>    for (rt = gt_ggc_deletable_rtab; *rt; rt++)
>  for (rti = *rt; rti->base != NULL; rti++)
> -  memset (rti->base, 0, rti->stride);
> +  memset (rti->base, 0, rti->stride * rti->nelt);
>  
>    for (rt = gt_ggc_rtab; *rt; rt++)
>  ggc_mark_root_tab (*rt);
> @@ -1293,3 +1293,24 @@ report_heap_memory_use ()
>  SIZE_AMOUNT (MALLINFO_FN ().arena));
>  #endif
>  }
> +
> +/* Forcibly clear all GTY roots.  */
> +
> +void
> +ggc_common_finalize ()
> +{
> +  const struct ggc_root_tab *const *rt;
> +  const_ggc_root_tab_t rti;
> +
> +  for (rt = gt_ggc_deletable_rtab; *rt; rt++)
> +    for (rti = *rt; rti->base != NULL; rti++)
> +  memset (rti->base, 0, rti->stride * rti->nelt);
> +
> +  for (rt = gt_ggc_rtab; *rt; rt++)
> +    for (rti = *rt; rti->base != NULL; rti++)
> +  memset (rti->base, 0, rti->stride * rti->nelt);
> +
> +  for (rt = gt_pch_scalar_rtab; *rt; rt++)
> +    for (rti = *rt; rti->base != NULL; rti++)
> +  memset (rti->base, 0, rti->stride * rti->nelt);
> +}
> diff --git a/gcc/ggc.h b/gcc/ggc.h
> index 34108e2f0061..3280314f8481 100644
> --- a/gcc/ggc.h
> +++ b/gcc/ggc.h
> @@ -368,4 +368,6 @@ inline 

Re: [PATCH] analyzer: Move gcc.dg/analyzer tests to c-c++-common (2) [PR96395]

2023-09-06 Thread Benjamin Priour via Gcc-patches
Hi David,
Thanks for the review.



On Tue, Sep 5, 2023 at 1:53 PM David Malcolm  wrote:

> On Mon, 2023-09-04 at 20:00 +0200, priour...@gmail.com wrote:
>
>
[...snip...]


> All of these "new" tests (apart from the "-noexcept" ones) look like
> they're meant to be existing tests that were moved, but where the copy
> of the test in gcc.dg/analyzer didn't get deleted, so they show up as a
> duplicate.  See the details below.
>

> >   * c-c++-common/analyzer/file-pr58237-noexcept.c: New test.
>
> When duplicating a test like this, the test isn't entirely "new", so
> please say something like this in the ChangeLog entry, to make it clear
> where it came from:
>
>
I actually wasn't sure about these -noexcept tests. They were part
of gcc.dg/analyzer, thus only gcc was running them. Exceptions
were not disabled *explicitly*, but since it was C, they weren't enabled
either.

Therefore, the -noexcept tests are basically a copy, but with an explicit
-fno-exceptions specification.
When I duplicated them in that way I was thinking about making it clear
that these tests fail in C++ with exceptions enabled, so that we would
already
have easy-to-spot failing tests to challenge a future exception support.

Though perhaps *not* duplicating the tests but rather simply specify
-fno-exceptions,
with a comment "Fails with exceptions" may be better.


> * c-c++-common/analyzer/file-pr58237-noexcept.c: New test,
> based on gcc.dg/analyzer/file-pr58237.c.
>
> >   * c-c++-common/analyzer/fopen-2.c: New test.
>
> Looks fopen-2.c is a move of the parts of gcc.dg/analyzer/fopen-1.c
> that can also be C++, so please state that in the ChangeLog.
>

Nods.

[...snip...]


> Nice - thanks.
>
> Can this be combined with the EQ_EXPR and NE_EXPR cases? (possibly
> updating the comment)  The code looks identical to me, but I might be
> misreading it.
>
>
Totally, I forgot to move it after making sure it worked.
Thanks.


> [...snip...]
>
> > diff --git a/gcc/testsuite/c-c++-common/analyzer/compound-assignment-1.c
> b/gcc/testsuite/c-c++-common/analyzer/compound-assignment-1.c
> > new file mode 100644
> > index 000..b208f58f09f
> > --- /dev/null
> > +++ b/gcc/testsuite/c-c++-common/analyzer/compound-assignment-1.c
> > @@ -0,0 +1,72 @@
> > +#include 
> > +
> > +struct ptr_wrapper
> > +{
> > +  int *ptr;
> > +};
> > +
> > +struct ptr_wrapper
> > +test_1 (void)
> > +{
> > +  struct ptr_wrapper r;
> > +  r.ptr = (int *) malloc (sizeof (int));
> > +  return r;
> > +}
>
> This looks the same as gcc.dg/analyzer/compound-assignment-1.c
>
> Should this be a move, rather than a new file?  i.e. is the patch
> missing a deletion of the file in the old location?
>
> [...snip...]
>
> > diff --git a/gcc/testsuite/c-c++-common/analyzer/infinite-recursion.c
> b/gcc/testsuite/c-c++-common/analyzer/infinite-recursion.c
> > new file mode 100644
> > index 000..6b7d25cfabe
> > --- /dev/null
> > +++ b/gcc/testsuite/c-c++-common/analyzer/infinite-recursion.c
>
> Likewise here for infinite-recursion.c.
>
> [...snip...]
>
> > diff --git
> a/gcc/testsuite/gcc.dg/analyzer/loop-0-up-to-n-by-1-with-iter-obj.c
> b/gcc/testsuite/c-c++-common/analyzer/loop-0-up-to-n-by-1-with-iter-obj.c
> > similarity index 97%
> > rename from
> gcc/testsuite/gcc.dg/analyzer/loop-0-up-to-n-by-1-with-iter-obj.c
> > rename to
> gcc/testsuite/c-c++-common/analyzer/loop-0-up-to-n-by-1-with-iter-obj.c
> > index 0172c9b324c..1b657697ef4 100644
> > --- a/gcc/testsuite/gcc.dg/analyzer/loop-0-up-to-n-by-1-with-iter-obj.c
> > +++
> b/gcc/testsuite/c-c++-common/analyzer/loop-0-up-to-n-by-1-with-iter-obj.c
> > @@ -1,6 +1,6 @@
> >  #include 
> >
> > -#include "analyzer-decls.h"
> > +#include "../../gcc.dg/analyzer/analyzer-decls.h"
> >
> >  struct iter
> >  {
> > @@ -45,7 +45,7 @@ void test(int n)
> >struct iter *it = iter_new (0, n, 1);
> >while (!iter_done_p (it))
> >  {
> > -  __analyzer_eval (it->val < n); /* { dg-warning "TRUE" "true" {
> xfail *-*-* } } */
> > +  __analyzer_eval (it->val < n); /* { dg-warning "TRUE" "true" } */
> >/* { dg-bogus "UNKNOWN" "unknown" { xfail *-*-* } .-1 } */
> >/* TODO(xfail^^^): ideally we ought to figure out i > 0 after 1st
> iteration.  */
> >
>
> Presumably due to the change to
> region_model::add_constraints_from_binop, right?
> Looking at that dg-bogus "UNKNOWN", do we still get an UNKNOWN here, or
> can that line be removed?
> If so, then the 3rd comment can presumably become:
>
>
The bogus here still make sense - without it there is an excess error -.
I had checked for it because I too thought it could be removed.
If I remember it correctly, we get UNKNOWN during the widening pass.


> >/* TODO: ideally we ought to figure out i > 0 after 1st
> iteration.  */
>
> [...snip...]
>
>
>
[...snip...]

Thanks for spotting the files I forgot to remove from gcc.dg.
Sorry about them, I had messed up my test folder when checking for arm-eabi,
and I apparently missed some duplicates when 

[PATCH 2/2] Experiment with adding an error code to an error

2023-09-06 Thread Arthur Cohen
From: David Malcolm 

---
 gcc/rust/rust-diagnostics.cc  | 11 +++
 gcc/rust/rust-diagnostics.h   | 18 ++
 gcc/rust/rust-gcc-diagnostics.cc  | 33 +++
 gcc/rust/typecheck/rust-casts.cc  |  2 +-
 .../rust/compile/bad_as_bool_char.rs  |  4 +--
 5 files changed, 65 insertions(+), 3 deletions(-)

diff --git a/gcc/rust/rust-diagnostics.cc b/gcc/rust/rust-diagnostics.cc
index 4e5c2ececd4..f29aec67652 100644
--- a/gcc/rust/rust-diagnostics.cc
+++ b/gcc/rust/rust-diagnostics.cc
@@ -166,6 +166,17 @@ rust_error_at (const Location location, const char *fmt, 
...)
   va_end (ap);
 }
 
+void
+rust_error_at (const RichLocation , const ErrorCode code,
+  const char *fmt, ...)
+{
+  va_list ap;
+
+  va_start (ap, fmt);
+  rust_be_error_at (location, code, expand_message (fmt, ap));
+  va_end (ap);
+}
+
 void
 rust_warning_at (const Location location, int opt, const char *fmt, ...)
 {
diff --git a/gcc/rust/rust-diagnostics.h b/gcc/rust/rust-diagnostics.h
index 43fee8baf4f..d198bd5736f 100644
--- a/gcc/rust/rust-diagnostics.h
+++ b/gcc/rust/rust-diagnostics.h
@@ -50,6 +50,18 @@
 
 // clang-format off
 // simple location
+
+struct ErrorCode
+{
+  explicit ErrorCode (const char *str) : m_str (str)
+  {
+gcc_assert (str);
+gcc_assert (str[0] == 'E');
+  }
+
+  const char *m_str;
+};
+
 extern void
 rust_internal_error_at (const Location, const char *fmt, ...)
   RUST_ATTRIBUTE_GCC_DIAG (2, 3)
@@ -72,6 +84,9 @@ rust_inform (const Location, const char *fmt, ...)
 extern void
 rust_error_at (const RichLocation &, const char *fmt, ...)
   RUST_ATTRIBUTE_GCC_DIAG (2, 3);
+extern void
+rust_error_at (const RichLocation &, const ErrorCode, const char *fmt, ...)
+  RUST_ATTRIBUTE_GCC_DIAG (3, 4);
 // clang-format on
 
 // These interfaces provide a way for the front end to ask for
@@ -97,6 +112,9 @@ rust_be_error_at (const Location, const std::string );
 extern void
 rust_be_error_at (const RichLocation &, const std::string );
 extern void
+rust_be_error_at (const RichLocation &, const ErrorCode,
+ const std::string );
+extern void
 rust_be_warning_at (const Location, int opt, const std::string );
 extern void
 rust_be_fatal_error (const Location, const std::string )
diff --git a/gcc/rust/rust-gcc-diagnostics.cc b/gcc/rust/rust-gcc-diagnostics.cc
index 72d2c068541..58c0a5654ea 100644
--- a/gcc/rust/rust-gcc-diagnostics.cc
+++ b/gcc/rust/rust-gcc-diagnostics.cc
@@ -22,6 +22,7 @@
 #include "rust-diagnostics.h"
 
 #include "options.h"
+#include "diagnostic-metadata.h"
 
 void
 rust_be_internal_error_at (const Location location, const std::string )
@@ -70,6 +71,38 @@ rust_be_error_at (const RichLocation , const 
std::string )
   error_at (_loc, "%s", errmsg.c_str ());
 }
 
+class rust_error_code_rule : public diagnostic_metadata::rule
+{
+public:
+  rust_error_code_rule (const ErrorCode code) : m_code (code) {}
+
+  char *make_description () const final override
+  {
+return xstrdup (m_code.m_str);
+  }
+
+  char *make_url () const final override
+  {
+return concat ("https://doc.rust-lang.org/error-index.html#;, m_code.m_str,
+  NULL);
+  }
+
+private:
+  const ErrorCode m_code;
+};
+
+void
+rust_be_error_at (const RichLocation , const ErrorCode code,
+ const std::string )
+{
+  /* TODO: 'error_at' would like a non-'const' 'rich_location *'.  */
+  rich_location _loc = const_cast (location.get ());
+  diagnostic_metadata m;
+  rust_error_code_rule rule (code);
+  m.add_rule (rule);
+  error_meta (_loc, m, "%s", errmsg.c_str ());
+}
+
 void
 rust_be_get_quotechars (const char **open_qu, const char **close_qu)
 {
diff --git a/gcc/rust/typecheck/rust-casts.cc b/gcc/rust/typecheck/rust-casts.cc
index e379216b948..987542e59c4 100644
--- a/gcc/rust/typecheck/rust-casts.cc
+++ b/gcc/rust/typecheck/rust-casts.cc
@@ -283,7 +283,7 @@ TypeCastRules::emit_cast_error () const
   RichLocation r (locus);
   r.add_range (from.get_locus ());
   r.add_range (to.get_locus ());
-  rust_error_at (r, "invalid cast %<%s%> to %<%s%>",
+  rust_error_at (r, ErrorCode ("E0054"), "invalid cast %<%s%> to %<%s%>",
 from.get_ty ()->get_name ().c_str (),
 to.get_ty ()->get_name ().c_str ());
 }
diff --git a/gcc/testsuite/rust/compile/bad_as_bool_char.rs 
b/gcc/testsuite/rust/compile/bad_as_bool_char.rs
index 91a28eebe00..9652915fe11 100644
--- a/gcc/testsuite/rust/compile/bad_as_bool_char.rs
+++ b/gcc/testsuite/rust/compile/bad_as_bool_char.rs
@@ -5,13 +5,13 @@ pub fn main ()
   let fone = t as f32;   // { dg-error "invalid cast" }
   let fzero = f as f64;  // { dg-error "invalid cast" }
 
-  let nb = 0u8 as bool;  // { dg-error "invalid cast" }
+  let nb = 0u8 as bool;  // { dg-error "invalid cast .u8. to .bool. 
\\\[E0054\\\]" }
   let nc = true as char; // { dg-error "invalid cast" }
 
   let a = 'a';
   let b = 'b';
   let fa = a as f32; // { dg-error "invalid cast" 

[PATCH 1/2] diagnostics: add error_meta

2023-09-06 Thread Arthur Cohen
From: David Malcolm 

---
 gcc/diagnostic-core.h |  3 +++
 gcc/diagnostic.cc | 15 +++
 2 files changed, 18 insertions(+)

diff --git a/gcc/diagnostic-core.h b/gcc/diagnostic-core.h
index 7334c79e8e6..c9e27fd2e6e 100644
--- a/gcc/diagnostic-core.h
+++ b/gcc/diagnostic-core.h
@@ -92,6 +92,9 @@ extern void error_n (location_t, unsigned HOST_WIDE_INT, 
const char *,
 extern void error_at (location_t, const char *, ...) ATTRIBUTE_GCC_DIAG(2,3);
 extern void error_at (rich_location *, const char *, ...)
   ATTRIBUTE_GCC_DIAG(2,3);
+extern void error_meta (rich_location *, const diagnostic_metadata &,
+   const char *, ...)
+  ATTRIBUTE_GCC_DIAG(3,4);
 extern void fatal_error (location_t, const char *, ...) ATTRIBUTE_GCC_DIAG(2,3)
  ATTRIBUTE_NORETURN;
 /* Pass one of the OPT_W* from options.h as the second parameter.  */
diff --git a/gcc/diagnostic.cc b/gcc/diagnostic.cc
index c523f215bae..65c0cfbf11a 100644
--- a/gcc/diagnostic.cc
+++ b/gcc/diagnostic.cc
@@ -2108,6 +2108,21 @@ error_at (rich_location *richloc, const char *gmsgid, 
...)
   va_end (ap);
 }
 
+/* Same as above, but with metadata.  */
+
+void
+error_meta (rich_location *richloc, const diagnostic_metadata ,
+   const char *gmsgid, ...)
+{
+  gcc_assert (richloc);
+
+  auto_diagnostic_group d;
+  va_list ap;
+  va_start (ap, gmsgid);
+  diagnostic_impl (richloc, , -1, gmsgid, , DK_ERROR);
+  va_end (ap);
+}
+
 /* "Sorry, not implemented."  Use for a language feature which is
required by the relevant specification but not implemented by GCC.
An object file will not be produced.  */
-- 
2.40.0



[PATCHSET] Add error metadata to diagnostics

2023-09-06 Thread Arthur Cohen
This short patchset from David Malcolm enables errors to contain extra
metadata - this is particularly useful for the Rust frontend, which will
rely on that implementation to emit standard Rust error codes [1].

This series of patches is necessary for much of our more recent
additions to the frontend, including the work of one of this year's GSoC
student, Mahad Muhammad, who has spent a lot of time working on emitting
these error codes from the Rust frontend for GCC.

We will soon resume upstreaming patches from our development repository
to the main GCC repository, in the hopes of distributing the Rust frontend
as part of the GCC 14.1 release.

[PATCH 1/2] diagnostics: add error_meta
[PATCH 2/2] Experiment with adding an error code to an error

Are these OK for trunk?

Kindly,

Arthur



[pushed] analyzer: implement kf_strstr [PR105899]

2023-09-06 Thread David Malcolm via Gcc-patches
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r14-3741-gf2d7a4001a3388.

gcc/analyzer/ChangeLog:
PR analyzer/105899
* kf.cc (class kf_strstr): New.
(kf_strstr::impl_call_post): New.
(register_known_functions): Register it.

gcc/testsuite/ChangeLog:
PR analyzer/105899
* c-c++-common/analyzer/strstr-1.c: New test.
---
 gcc/analyzer/kf.cc| 96 +++
 .../c-c++-common/analyzer/strstr-1.c  | 54 +++
 2 files changed, 150 insertions(+)
 create mode 100644 gcc/testsuite/c-c++-common/analyzer/strstr-1.c

diff --git a/gcc/analyzer/kf.cc b/gcc/analyzer/kf.cc
index 8a45c329c282..92959891fe44 100644
--- a/gcc/analyzer/kf.cc
+++ b/gcc/analyzer/kf.cc
@@ -1585,6 +1585,100 @@ public:
   }
 };
 
+/* Handler for "strstr" and "__builtin_strstr".
+ extern char *strstr (const char* str, const char* substr);
+   See e.g. https://en.cppreference.com/w/c/string/byte/strstr  */
+
+class kf_strstr : public builtin_known_function
+{
+public:
+  bool matches_call_types_p (const call_details ) const final override
+  {
+return (cd.num_args () == 2
+   && cd.arg_is_pointer_p (0)
+   && cd.arg_is_pointer_p (1));
+  }
+  enum built_in_function builtin_code () const final override
+  {
+return BUILT_IN_STRSTR;
+  }
+  void impl_call_pre (const call_details ) const final override
+  {
+cd.check_for_null_terminated_string_arg (0);
+cd.check_for_null_terminated_string_arg (1);
+  }
+  void impl_call_post (const call_details ) const final override;
+};
+
+void
+kf_strstr::impl_call_post (const call_details ) const
+{
+  class strstr_call_info : public call_info
+  {
+  public:
+strstr_call_info (const call_details , bool found)
+: call_info (cd), m_found (found)
+{
+}
+
+label_text get_desc (bool can_colorize) const final override
+{
+  if (m_found)
+   return make_label_text (can_colorize,
+   "when %qE returns non-NULL",
+   get_fndecl ());
+  else
+   return make_label_text (can_colorize,
+   "when %qE returns NULL",
+   get_fndecl ());
+}
+
+bool update_model (region_model *model,
+  const exploded_edge *,
+  region_model_context *ctxt) const final override
+{
+  const call_details cd (get_call_details (model, ctxt));
+  if (tree lhs_type = cd.get_lhs_type ())
+   {
+ region_model_manager *mgr = model->get_manager ();
+ const svalue *result;
+ if (m_found)
+   {
+ const svalue *str_sval = cd.get_arg_svalue (0);
+ const region *str_reg
+   = model->deref_rvalue (str_sval, cd.get_arg_tree (0),
+  cd.get_ctxt ());
+ /* We want str_sval + OFFSET for some unknown OFFSET.
+Use a conjured_svalue to represent the offset,
+using the str_reg as the id of the conjured_svalue.  */
+ const svalue *offset
+   = mgr->get_or_create_conjured_svalue (size_type_node,
+ cd.get_call_stmt (),
+ str_reg,
+ conjured_purge (model,
+ ctxt));
+ result = mgr->get_or_create_binop (lhs_type, POINTER_PLUS_EXPR,
+str_sval, offset);
+   }
+ else
+   result = mgr->get_or_create_int_cst (lhs_type, 0);
+ cd.maybe_set_lhs (result);
+   }
+  return true;
+}
+  private:
+bool m_found;
+  };
+
+  /* Body of kf_strstr::impl_call_post.  */
+  if (cd.get_ctxt ())
+{
+  cd.get_ctxt ()->bifurcate (make_unique (cd, false));
+  cd.get_ctxt ()->bifurcate (make_unique (cd, true));
+  cd.get_ctxt ()->terminate_path ();
+}
+}
+
 class kf_ubsan_bounds : public internal_known_function
 {
   /* Empty.  */
@@ -1806,6 +1900,8 @@ register_known_functions (known_function_manager )
 kfm.add ("__builtin_strndup", make_unique ());
 kfm.add ("strlen", make_unique ());
 kfm.add ("__builtin_strlen", make_unique ());
+kfm.add ("strstr", make_unique ());
+kfm.add ("__builtin_strstr", make_unique ());
 
 register_atomic_builtins (kfm);
 register_varargs_builtins (kfm);
diff --git a/gcc/testsuite/c-c++-common/analyzer/strstr-1.c 
b/gcc/testsuite/c-c++-common/analyzer/strstr-1.c
new file mode 100644
index ..469e6a817d0d
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/analyzer/strstr-1.c
@@ -0,0 +1,54 @@
+/* See e.g. https://en.cppreference.com/w/c/string/byte/strstr  */
+
+/* { dg-additional-options "-fpermissive" { target c++ } } */
+
+#include 

[pushed] analyzer: implement kf_strncpy [PR105899]

2023-09-06 Thread David Malcolm via Gcc-patches
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r14-3740-gb51cde34d4e750.

gcc/analyzer/ChangeLog:
PR analyzer/105899
* kf.cc (class kf_strncpy): New.
(kf_strncpy::impl_call_post): New.
(register_known_functions): Register it.
* region-model.cc (region_model::read_bytes): Handle unknown
number of bytes.

gcc/testsuite/ChangeLog:
PR analyzer/105899
* c-c++-common/analyzer/null-terminated-strings-2.c: New test.
* c-c++-common/analyzer/overlapping-buffers.c: Update dg-bogus
directives to avoid clashing with note from  that might
happen to have the same line number.  Add strpncpy test coverage.
* c-c++-common/analyzer/strncpy-1.c: New test.
* gcc.dg/analyzer/null-terminated-strings-1.c
(test_filled_nonzero): New.
(void test_filled_zero): New.
(test_filled_symbolic): New.
---
 gcc/analyzer/kf.cc| 182 ++
 gcc/analyzer/region-model.cc  |   2 +
 .../analyzer/null-terminated-strings-2.c  |  17 ++
 .../analyzer/overlapping-buffers.c|  24 ++-
 .../c-c++-common/analyzer/strncpy-1.c | 157 +++
 .../analyzer/null-terminated-strings-1.c  |  24 +++
 6 files changed, 398 insertions(+), 8 deletions(-)
 create mode 100644 
gcc/testsuite/c-c++-common/analyzer/null-terminated-strings-2.c
 create mode 100644 gcc/testsuite/c-c++-common/analyzer/strncpy-1.c

diff --git a/gcc/analyzer/kf.cc b/gcc/analyzer/kf.cc
index a62227729991..8a45c329c282 100644
--- a/gcc/analyzer/kf.cc
+++ b/gcc/analyzer/kf.cc
@@ -1375,6 +1375,186 @@ make_kf_strlen ()
   return make_unique ();
 }
 
+/* Handler for "strncpy" and "__builtin_strncpy".
+   See e.g. https://en.cppreference.com/w/c/string/byte/strncpy
+
+ extern char *strncpy (char *dst, const char *src, size_t count);
+
+   Handle this by splitting into two outcomes:
+   (a) truncated read from "src" of "count" bytes,
+   writing "count" bytes to "dst"
+   (b) read from "src" of up to (and including) the null terminator,
+   where the number of bytes read < "count" bytes,
+   writing those bytes to "dst", and zero-filling the rest,
+   up to "count".  */
+
+class kf_strncpy : public builtin_known_function
+{
+public:
+  bool matches_call_types_p (const call_details ) const final override
+  {
+return (cd.num_args () == 3
+   && cd.arg_is_pointer_p (0)
+   && cd.arg_is_pointer_p (1)
+   && cd.arg_is_integral_p (2));
+  }
+  enum built_in_function builtin_code () const final override
+  {
+return BUILT_IN_STRNCPY;
+  }
+  void impl_call_post (const call_details ) const final override;
+};
+
+void
+kf_strncpy::impl_call_post (const call_details ) const
+{
+  class strncpy_call_info : public call_info
+  {
+  public:
+strncpy_call_info (const call_details ,
+  const svalue *num_bytes_with_terminator_sval,
+  bool truncated_read)
+: call_info (cd),
+  m_num_bytes_with_terminator_sval (num_bytes_with_terminator_sval),
+  m_truncated_read (truncated_read)
+{
+}
+
+label_text get_desc (bool can_colorize) const final override
+{
+  if (m_truncated_read)
+   return make_label_text (can_colorize,
+   "when %qE truncates the source string",
+   get_fndecl ());
+  else
+   return make_label_text (can_colorize,
+   "when %qE copies the full source string",
+   get_fndecl ());
+}
+
+bool update_model (region_model *model,
+  const exploded_edge *,
+  region_model_context *ctxt) const final override
+{
+  const call_details cd (get_call_details (model, ctxt));
+
+  const svalue *dest_sval = cd.get_arg_svalue (0);
+  const region *dest_reg
+   = model->deref_rvalue (dest_sval, cd.get_arg_tree (0), ctxt);
+
+  const svalue *src_sval = cd.get_arg_svalue (1);
+  const region *src_reg
+   = model->deref_rvalue (src_sval, cd.get_arg_tree (1), ctxt);
+
+  const svalue *count_sval = cd.get_arg_svalue (2);
+
+  /* strncpy returns the initial param.  */
+  cd.maybe_set_lhs (dest_sval);
+
+  const svalue *num_bytes_read_sval;
+  if (m_truncated_read)
+   {
+ /* Truncated read.  */
+ num_bytes_read_sval = count_sval;
+
+ if (m_num_bytes_with_terminator_sval)
+   {
+ /* The terminator is after the limit.  */
+ if (!model->add_constraint (m_num_bytes_with_terminator_sval,
+ GT_EXPR,
+ count_sval,
+ ctxt))
+   return false;
+   }
+ else
+   {
+ /* We don't know where the terminator is, or if there is 

[pushed] analyzer: add ctxt to fill_region/zero_fill_region

2023-09-06 Thread David Malcolm via Gcc-patches
I noticed that region_model's fill_region/zero_fill_region member
functions weren't checking that the write to the region was valid.

Fixed thusly.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r14-3739-gb923978a6ec447.

gcc/analyzer/ChangeLog:
* kf.cc (kf_calloc::impl_call_pre): Pass ctxt to zero_fill_region.
(kf_memset::impl_call_pre): Move responsibility for calling
check_region_for_write to fill_region.
* region-model.cc (region_model::on_assignment): Pass ctxt to
zero_fill_region.
(region_model::fill_region): Add "ctxt" param, using it to call
check_region_for_write.
(region_model::zero_fill_region): Likewise.
* region-model.h (region_model::fill_region): Add "ctxt" param.
(region_model::zero_fill_region): Likewise.

gcc/testsuite/ChangeLog:
* gcc.dg/plugin/analyzer_cpython_plugin.c: Pass ctxt to
zero_fill_region.
---
 gcc/analyzer/kf.cc|  7 ++-
 gcc/analyzer/region-model.cc  | 19 ++-
 gcc/analyzer/region-model.h   |  7 +--
 .../gcc.dg/plugin/analyzer_cpython_plugin.c   |  2 +-
 4 files changed, 22 insertions(+), 13 deletions(-)

diff --git a/gcc/analyzer/kf.cc b/gcc/analyzer/kf.cc
index e5bd7459f271..a62227729991 100644
--- a/gcc/analyzer/kf.cc
+++ b/gcc/analyzer/kf.cc
@@ -358,7 +358,7 @@ kf_calloc::impl_call_pre (const call_details ) const
 = model->get_or_create_region_for_heap_alloc (prod_sval, cd.get_ctxt ());
   const region *sized_reg
 = mgr->get_sized_region (new_reg, NULL_TREE, prod_sval);
-  model->zero_fill_region (sized_reg);
+  model->zero_fill_region (sized_reg, cd.get_ctxt ());
   if (cd.get_lhs_type ())
 {
   const svalue *ptr_sval
@@ -650,10 +650,7 @@ kf_memset::impl_call_pre (const call_details ) const
   const region *sized_dest_reg = mgr->get_sized_region (dest_reg,
NULL_TREE,
num_bytes_sval);
-  model->check_region_for_write (sized_dest_reg,
-nullptr,
-cd.get_ctxt ());
-  model->fill_region (sized_dest_reg, fill_value_u8);
+  model->fill_region (sized_dest_reg, fill_value_u8, cd.get_ctxt ());
 
   cd.maybe_set_lhs (dest_sval);
 }
diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
index 82bc3b2c3826..6be0ad72aaae 100644
--- a/gcc/analyzer/region-model.cc
+++ b/gcc/analyzer/region-model.cc
@@ -1204,7 +1204,7 @@ region_model::on_assignment (const gassign *assign, 
region_model_context *ctxt)
/* Any CONSTRUCTOR that survives to this point is either
   just a zero-init of everything, or a vector.  */
if (!CONSTRUCTOR_NO_CLEARING (rhs1))
- zero_fill_region (lhs_reg);
+ zero_fill_region (lhs_reg, ctxt);
unsigned ix;
tree index;
tree val;
@@ -3929,19 +3929,28 @@ region_model::purge_region (const region *reg)
   m_store.purge_region (m_mgr->get_store_manager(), reg);
 }
 
-/* Fill REG with SVAL.  */
+/* Fill REG with SVAL.
+   Use CTXT to report any warnings associated with the write
+   (e.g. out-of-bounds).  */
 
 void
-region_model::fill_region (const region *reg, const svalue *sval)
+region_model::fill_region (const region *reg,
+  const svalue *sval,
+  region_model_context *ctxt)
 {
+  check_region_for_write (reg, nullptr, ctxt);
   m_store.fill_region (m_mgr->get_store_manager(), reg, sval);
 }
 
-/* Zero-fill REG.  */
+/* Zero-fill REG.
+   Use CTXT to report any warnings associated with the write
+   (e.g. out-of-bounds).  */
 
 void
-region_model::zero_fill_region (const region *reg)
+region_model::zero_fill_region (const region *reg,
+   region_model_context *ctxt)
 {
+  check_region_for_write (reg, nullptr, ctxt);
   m_store.zero_fill_region (m_mgr->get_store_manager(), reg);
 }
 
diff --git a/gcc/analyzer/region-model.h b/gcc/analyzer/region-model.h
index bb50ff12b12e..625f68805361 100644
--- a/gcc/analyzer/region-model.h
+++ b/gcc/analyzer/region-model.h
@@ -370,8 +370,11 @@ class region_model
   void set_value (tree lhs, tree rhs, region_model_context *ctxt);
   void clobber_region (const region *reg);
   void purge_region (const region *reg);
-  void fill_region (const region *reg, const svalue *sval);
-  void zero_fill_region (const region *reg);
+  void fill_region (const region *reg,
+   const svalue *sval,
+   region_model_context *ctxt);
+  void zero_fill_region (const region *reg,
+region_model_context *ctxt);
   void write_bytes (const region *dest_reg,
const svalue *num_bytes_sval,
const svalue *sval,
diff --git a/gcc/testsuite/gcc.dg/plugin/analyzer_cpython_plugin.c 

[PATCH] ggc, jit: forcibly clear GTY roots in jit

2023-09-06 Thread David Malcolm via Gcc-patches
As part of Antoyo's work on supporting LTO in rustc_codegen_gcc, he
noticed an ICE inside libgccjit when compiling certain rust files.

Debugging libgccjit showed that outdated information from a previous
in-memory compile was referring to ad-hoc locations in the previous
compile's line_table.

The issue turned out to be the function decls in internal_fn_fnspec_array
from the previous compile keeping alive the symtab nodes for these
functions, and from this finding other functions in the previous
compile, walking their CFGs, and finding ad-hoc data pointers in an edge
with a location_t using ad-hoc data from the previous line_table
instance, and thus a use-after-free ICE attempting to use this ad-hoc
data.

Previously in toplev::finalize we've fixed global state "piecemeal" by
calling out to individual source_name_cc_finalize functions.  However,
it occurred to me that we have run-time information on where the
GTY-marked pointers are.

Hence this patch takes something of a "big hammer" approach by adding a
new ggc_common_finalize that walks the GC roots, zeroing all of the
pointers.  I stepped through this in the debugger and observed that, in
particular, this correctly zeroes the internal_fn_fnspec_array at the end
of a libgccjit compile.  Antoyo reports that this fixes the ICE for him.
Doing so uncovered an ICE with libgccjit in dwarf2cfi.cc due to reuse of
global variables from the previous compile, which this patch also fixes.

I noticed that in ggc_mark_roots when clearing deletable roots we only
clear the initial element in each gcc_root_tab_t.  This looks like a
latent bug to me, which the patch fixes.  That said, there don't seem to
be any deletable roots where the number of elements != 1.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.

OK for trunk?

Thanks
Dave

gcc/ChangeLog:
* dwarf2cfi.cc (dwarf2cfi_cc_finalize): New.
* dwarf2out.h (dwarf2cfi_cc_finalize): New decl.
* ggc-common.cc (ggc_mark_roots): Multiply by rti->nelt when
clearing the deletable gcc_root_tab_t.
(ggc_common_finalize): New.
* ggc.h (ggc_common_finalize): New decl.
* toplev.cc (toplev::finalize): Call dwarf2cfi_cc_finalize and
ggc_common_finalize.
---
 gcc/dwarf2cfi.cc  |  9 +
 gcc/dwarf2out.h   |  1 +
 gcc/ggc-common.cc | 23 ++-
 gcc/ggc.h |  2 ++
 gcc/toplev.cc |  3 +++
 5 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/gcc/dwarf2cfi.cc b/gcc/dwarf2cfi.cc
index ddc728f4ad00..f1777c0a4cf1 100644
--- a/gcc/dwarf2cfi.cc
+++ b/gcc/dwarf2cfi.cc
@@ -3822,4 +3822,13 @@ make_pass_dwarf2_frame (gcc::context *ctxt)
   return new pass_dwarf2_frame (ctxt);
 }
 
+void dwarf2cfi_cc_finalize ()
+{
+  add_cfi_insn = NULL;
+  add_cfi_vec = NULL;
+  cur_trace = NULL;
+  cur_row = NULL;
+  cur_cfa = NULL;
+}
+
 #include "gt-dwarf2cfi.h"
diff --git a/gcc/dwarf2out.h b/gcc/dwarf2out.h
index 870b56a6a372..61a996050ff9 100644
--- a/gcc/dwarf2out.h
+++ b/gcc/dwarf2out.h
@@ -419,6 +419,7 @@ struct fixed_point_type_info
 } scale_factor;
 };
 
+void dwarf2cfi_cc_finalize (void);
 void dwarf2out_cc_finalize (void);
 
 /* Some DWARF internals are exposed for the needs of DWARF-based debug
diff --git a/gcc/ggc-common.cc b/gcc/ggc-common.cc
index bed7a9d4d021..95803fa95a17 100644
--- a/gcc/ggc-common.cc
+++ b/gcc/ggc-common.cc
@@ -86,7 +86,7 @@ ggc_mark_roots (void)
 
   for (rt = gt_ggc_deletable_rtab; *rt; rt++)
 for (rti = *rt; rti->base != NULL; rti++)
-  memset (rti->base, 0, rti->stride);
+  memset (rti->base, 0, rti->stride * rti->nelt);
 
   for (rt = gt_ggc_rtab; *rt; rt++)
 ggc_mark_root_tab (*rt);
@@ -1293,3 +1293,24 @@ report_heap_memory_use ()
 SIZE_AMOUNT (MALLINFO_FN ().arena));
 #endif
 }
+
+/* Forcibly clear all GTY roots.  */
+
+void
+ggc_common_finalize ()
+{
+  const struct ggc_root_tab *const *rt;
+  const_ggc_root_tab_t rti;
+
+  for (rt = gt_ggc_deletable_rtab; *rt; rt++)
+for (rti = *rt; rti->base != NULL; rti++)
+  memset (rti->base, 0, rti->stride * rti->nelt);
+
+  for (rt = gt_ggc_rtab; *rt; rt++)
+for (rti = *rt; rti->base != NULL; rti++)
+  memset (rti->base, 0, rti->stride * rti->nelt);
+
+  for (rt = gt_pch_scalar_rtab; *rt; rt++)
+for (rti = *rt; rti->base != NULL; rti++)
+  memset (rti->base, 0, rti->stride * rti->nelt);
+}
diff --git a/gcc/ggc.h b/gcc/ggc.h
index 34108e2f0061..3280314f8481 100644
--- a/gcc/ggc.h
+++ b/gcc/ggc.h
@@ -368,4 +368,6 @@ inline void gt_ggc_mx (unsigned long int) { }
 inline void gt_ggc_mx (long long int) { }
 inline void gt_ggc_mx (unsigned long long int) { }
 
+extern void ggc_common_finalize ();
+
 #endif
diff --git a/gcc/toplev.cc b/gcc/toplev.cc
index 6c1a6f443c16..db62e3e995ec 100644
--- a/gcc/toplev.cc
+++ b/gcc/toplev.cc
@@ -2336,6 +2336,7 @@ toplev::finalize (void)
   cgraph_cc_finalize ();
   cgraphunit_cc_finalize ();
   symtab_thunks_cc_finalize ();
+  dwarf2cfi_cc_finalize ();
   

Re: [PATCH] RISC-V: Remove unreasonable TARGET_64BIT for VLS modes with size = 64bit

2023-09-06 Thread Robin Dapp via Gcc-patches
LGTM.

Regards
 Robin



Re: [PATCH] RISC-V: Fix VSETVL PASS AVL/VL fetch bug[111295]

2023-09-06 Thread Robin Dapp via Gcc-patches
OK.

Regards
 Robin


Re: [PATCH v3] RISC-V: Add autovec FP binary operations.

2023-09-06 Thread Robin Dapp via Gcc-patches


Hi Lehua,

> May I ask if the compiler options "-march=rv64gcv_zvfh -mabi=lp64d"
> should be removed? Because we don't specify -march and -mabi when we
> run testcase (so but why we need to specify the -march and -mabi in
> this target check?), we run it with the default values. Assuming that
> the default is rv64gcv_zvfh_zfh, `riscv_vector` check will fail
> because compile and link with -march=rv64gcv will throw the following
> error if I doesn't compile a multilibs compilers. But in fact
> rv64gcv_zvfh_zfh contains rv64gcv, we should not let this case report
> link error.:

Yes, you're right, this should not be necessary.  This is more of a
test for the execution environment than the compiler.  I think Juzhe
removed it already in his patch that enables the vector test suite.
In the future we would use the checks that Joern added, not sure if
they are already upstream.

Regards
 Robin



Re: [PATCH V2] RISC-V: Support Dynamic LMUL Cost model

2023-09-06 Thread Robin Dapp via Gcc-patches
Hi Juzhe,

general remark upfront:  Please add function-level comments for all
functions.  This makes reading and reviewing much easier.  I had to sweep
back and forth quite a bit.

> +
> +static int
> +get_last_live_range (const vec _ranges, tree var)
> +{
> +  unsigned int ix;
> +  var_live_range *live_range;
> +  FOR_EACH_VEC_ELT_REVERSE (live_ranges, ix, live_range)
> +if (live_range->var == var)
> +  return ix;
> +  return -1;
> +}

>From reading the usage site of this function it looks like we could benefit
from having the live ranges be a hash_map as well?  That way we wouldn't
need to scan through the list every time.  Something like
hash_map>.  It looks like we only consider the range
end anyway.

> +   int index = get_last_live_range (live_ranges, var);

That way we could avoid some worst-case behavior here for pathological
inputs.

> +   if (index == -1)
> + {
> +   var_live_range range = {var, 0, point};
> +   live_ranges.safe_push (range);
> + }

Please add a comment that we assume the variable is live from the start
of this block. 

> +   else
> + live_ranges[index].end = point;

And here a comment that we will grow the live range for each use.

> +static bool
> +live_range_conflict_p (const var_live_range _range1,
> +const var_live_range _range2)
> +{
> +  if (live_range1.start >= live_range2.end)
> +return false;
> +  if (live_range1.end <= live_range2.start)
> +return false;
> +  if (live_range2.start >= live_range1.end)
> +return false;
> +  if (live_range2.end <= live_range1.start)
> +return false;
> +  return true;
> +}

Rename to live_range_overlap_p and simplify to
 return a.end >= b.start || b.end >= a.start;

> +
> +static unsigned int
> +max_number_of_live_regs (const basic_block bb,
> +  const vec _ranges,
> +  machine_mode biggest_mode, int lmul)
> +{
> +  unsigned int max_nregs = 0;
> +  unsigned int i, j, k;
> +  unsigned int live_point = 0;
> +  for (i = 0; i < live_ranges.length (); i++)
> +{
> +  auto_vec conflict_live_ranges;
> +  var_live_range live_range = live_ranges[i];
> +  conflict_live_ranges.safe_push (live_range);
> +  unsigned int min_point = live_range.start;
> +  unsigned int max_point = live_range.end;
> +  for (j = 0; j < live_ranges.length (); j++)
> + {
> +   if (j == i)
> + continue;
> +   if (live_range_conflict_p (live_range, live_ranges[j]))
> + {
> +   conflict_live_ranges.safe_push (live_ranges[j]);
> +   min_point
> + = std::min (min_point, (unsigned int) live_ranges[j].start);
> +   max_point
> + = std::max (max_point, (unsigned int) live_ranges[j].end);
> + }
> + }
> +  for (j = min_point; j <= max_point; j++)
> + {
> +   unsigned int nregs = 0;
> +   for (k = 0; k < conflict_live_ranges.length (); k++)
> + {
> +   if (j >= (unsigned int) conflict_live_ranges[k].start
> +   && j <= (unsigned int) conflict_live_ranges[k].end)
> + {
> +   machine_mode mode
> + = TYPE_MODE (TREE_TYPE (conflict_live_ranges[k].var));
> +   nregs += compute_nregs_for_mode (mode, biggest_mode, lmul);
> + }
> + }
> +   if (nregs > max_nregs)
> + {
> +   max_nregs = nregs;
> +   live_point = j;
> + }
> + }
> +}

This looks pretty quadratic in the number of live ranges (or even cubic?).
Can't it be done more efficiently using a sliding-window approach by sorting
the live ranges according to their start point before?
Also std::min/max -> MIN/MAX.

> +
> +  /* Collect user explicit RVV type.  */
> +  hash_set all_preds = get_all_predecessors (bb);
> +  hash_set all_succs = get_all_successors (bb);

As mentioned before, maybe dominator info could help here?

> +  for (i = 0; i < cfun->gimple_df->ssa_names->length (); i++)
> +{
> +  tree t = ssa_name (i);
> +  if (!t)
> + continue;
> +  machine_mode mode = TYPE_MODE (TREE_TYPE (t));
> +  if (!lookup_vector_type_attribute (TREE_TYPE (t))
> +   && !riscv_v_ext_vls_mode_p (mode))
> + continue;
> +
> +  gimple *def = SSA_NAME_DEF_STMT (t);
> +  if (gimple_bb (def) && !all_preds.contains (gimple_bb (def)))
> + continue;
> +  const ssa_use_operand_t *const head = &(SSA_NAME_IMM_USE_NODE (t));
> +  const ssa_use_operand_t *ptr;
> +
> +  for (ptr = head->next; ptr != head; ptr = ptr->next)
> + {
> +   if (USE_STMT (ptr) && !is_gimple_debug (USE_STMT (ptr)))
> + {
> +   if (all_succs.contains (gimple_bb (USE_STMT (ptr
> + {

Reverse the conditions and continue, i.e. if (!USE_STMT || is_gimple_debug
 || !all_succs.contains).

> +
> +static int
> 

RE: [PATCH v1] RISC-V: Fix incorrect folder for VRGATHERI16 test case

2023-09-06 Thread Li, Pan2 via Gcc-patches
Committed, thanks Juzhe and sorry for my silly mistake.

Pan

From: juzhe.zhong 
Sent: Wednesday, September 6, 2023 8:53 PM
To: Li, Pan2 
Cc: gcc-patches@gcc.gnu.org; Li, Pan2 ; Wang, Yanzhang 
; kito.ch...@gmail.com
Subject: Re: [PATCH v1] RISC-V: Fix incorrect folder for VRGATHERI16 test case

lgtm
 Replied Message 
From
pan2...@intel.com
Date
09/06/2023 20:52
To
gcc-patches@gcc.gnu.org
Cc
juzhe.zh...@rivai.ai,
pan2...@intel.com,
yanzhang.w...@intel.com,
kito.ch...@gmail.com
Subject
[PATCH v1] RISC-V: Fix incorrect folder for VRGATHERI16 test case



[PATCH v1] RISC-V: Fix incorrect folder for VRGATHERI16 test case

2023-09-06 Thread Pan Li via Gcc-patches
From: Pan Li 

Put the test file to the incorrect folder, this patch would like to
fix it.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/intrisinc-vrgatherei16.c: Moved to...
* gcc.target/riscv/rvv/base/intrisinc-vrgatherei16.c: ...here.

Signed-off-by: Pan Li 
---
 .../gcc.target/riscv/rvv/{ => base}/intrisinc-vrgatherei16.c  | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename gcc/testsuite/gcc.target/riscv/rvv/{ => base}/intrisinc-vrgatherei16.c 
(100%)

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/intrisinc-vrgatherei16.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/intrisinc-vrgatherei16.c
similarity index 100%
rename from gcc/testsuite/gcc.target/riscv/rvv/intrisinc-vrgatherei16.c
rename to gcc/testsuite/gcc.target/riscv/rvv/base/intrisinc-vrgatherei16.c
-- 
2.34.1



[PATCH 2/2] ARC: Use intrinsics for __builtin_sub_overflow*()

2023-09-06 Thread Shahab Vahedi via Gcc-patches
This patch covers signed and unsigned subtractions.  The generated code
would be something along these lines:

signed:
  sub.f   r0, r1, r2
  b.v @label

unsigned:
  sub.f   r0, r1, r2
  b.c @label

gcc/ChangeLog:

* config/arc/arc.md (subsi3_v): New insn.
(subvsi4): New expand.
(subsi3_c): New insn.
(usubvsi4): New expand.

gcc/testsuite/ChangeLog:

* gcc.target/arc/overflow-2.c: New.

Signed-off-by: Shahab Vahedi 
---
 gcc/config/arc/arc.md | 48 +++
 gcc/testsuite/gcc.target/arc/overflow-2.c | 97 +++
 2 files changed, 145 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/arc/overflow-2.c

diff --git a/gcc/config/arc/arc.md b/gcc/config/arc/arc.md
index 9d011f6b4a9..34e9e1a7f1d 100644
--- a/gcc/config/arc/arc.md
+++ b/gcc/config/arc/arc.md
@@ -2973,6 +2973,54 @@ archs4x, archs4xd"
   (set_attr "cpu_facility" "*,cd,*,*,*,*,*,*,*,*")
   ])
 
+(define_insn "subsi3_v"
+  [(set (match_operand:SI  0 "register_operand"  "=r,r,r,  r")
+   (minus:SI (match_operand:SI 1 "register_operand"   "r,r,0,  r")
+ (match_operand:SI 2 "nonmemory_operand"  "r,L,I,C32")))
+   (set (reg:CC_V CC_REG)
+   (compare:CC_V (sign_extend:DI (minus:SI (match_dup 1)
+   (match_dup 2)))
+ (minus:DI (sign_extend:DI (match_dup 1))
+   (sign_extend:DI (match_dup 2)]
+   ""
+   "sub.f\\t%0,%1,%2"
+   [(set_attr "cond"   "set")
+(set_attr "type"   "compare")
+(set_attr "length" "4,4,4,8")])
+
+(define_expand "subvsi4"
+ [(match_operand:SI 0 "register_operand")
+  (match_operand:SI 1 "register_operand")
+  (match_operand:SI 2 "nonmemory_operand")
+  (label_ref (match_operand 3 "" ""))]
+  ""
+  "emit_insn (gen_subsi3_v (operands[0], operands[1], operands[2]));
+   arc_gen_unlikely_cbranch (NE, CC_Vmode, operands[3]);
+   DONE;")
+
+(define_insn "subsi3_c"
+  [(set (match_operand:SI  0 "register_operand"  "=r,r,r,  r")
+   (minus:SI (match_operand:SI 1 "register_operand"   "r,r,0,  r")
+ (match_operand:SI 2 "nonmemory_operand"  "r,L,I,C32")))
+   (set (reg:CC_C CC_REG)
+   (compare:CC_C (match_dup 1)
+ (match_dup 2)))]
+   ""
+   "sub.f\\t%0,%1,%2"
+   [(set_attr "cond"   "set")
+(set_attr "type"   "compare")
+(set_attr "length" "4,4,4,8")])
+
+(define_expand "usubvsi4"
+  [(match_operand:SI 0 "register_operand")
+   (match_operand:SI 1 "register_operand")
+   (match_operand:SI 2 "nonmemory_operand")
+   (label_ref (match_operand 3 "" ""))]
+   ""
+   "emit_insn (gen_subsi3_c (operands[0], operands[1], operands[2]));
+arc_gen_unlikely_cbranch (LTU, CC_Cmode, operands[3]);
+DONE;")
+
 (define_expand "subdi3"
   [(set (match_operand:DI 0 "register_operand" "")
(minus:DI (match_operand:DI 1 "register_operand" "")
diff --git a/gcc/testsuite/gcc.target/arc/overflow-2.c 
b/gcc/testsuite/gcc.target/arc/overflow-2.c
new file mode 100644
index 000..b4de8c03b22
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arc/overflow-2.c
@@ -0,0 +1,97 @@
+/* { dg-do compile } */
+/* { dg-options "-O1" } */
+
+#include 
+#include 
+
+/*
+ * sub.f  r0,r0,r1
+ * st_s   r0,[r2]
+ * mov_s  r0,1
+ * j_s.d  [blink]
+ * mov.nv r0,0
+ */
+bool sub_overflow (int32_t a, int32_t b, int32_t *res)
+{
+  return __builtin_sub_overflow (a, b, res);
+}
+
+/*
+ * sub.f  r0,r0,-1234
+ * st_s   r0,[r1]
+ * mov_s  r0,1
+ * j_s.d  [blink]
+ * mov.nv r0,0
+ */
+bool subi_overflow (int32_t a, int32_t *res)
+{
+  return __builtin_sub_overflow (a, -1234, res);
+}
+
+/*
+ * sub.f  r3,r0,r1
+ * st_s   r3,[r2]
+ * j_s.d  [blink]
+ * setlo  r0,r0,r1
+ */
+bool usub_overflow (uint32_t a, uint32_t b, uint32_t *res)
+{
+  return __builtin_sub_overflow (a, b, res);
+}
+
+/*
+ * sub.f  r2,r0,4321
+ * seths  r0,4320,r0
+ * j_s.d  [blink]
+ * st_s   r2,[r1]
+ */
+bool usubi_overflow (uint32_t a, uint32_t *res)
+{
+  return __builtin_sub_overflow (a, 4321, res);
+}
+
+/*
+ * sub.f  r0,r0,r1
+ * mov_s  r0,1
+ * j_s.d  [blink]
+ * mov.nv r0,0
+ */
+bool sub_overflow_p (int32_t a, int32_t b, int32_t res)
+{
+  return __builtin_sub_overflow_p (a, b, res);
+}
+
+/*
+ * sub.f  r0,r0,-1000
+ * mov_s  r0,1
+ * j_s.d  [blink]
+ * mov.nv r0,0
+ */
+bool subi_overflow_p (int32_t a, int32_t res)
+{
+  return __builtin_sub_overflow_p (a, -1000, res);
+}
+
+/*
+ * j_s.d  [blink]
+ * setlo  r0,r0,r1
+ */
+bool usub_overflow_p (uint32_t a, uint32_t b, uint32_t res)
+{
+  return __builtin_sub_overflow_p (a, b, res);
+}
+
+/*
+ * seths  r0,1999,r0
+ * j_s.d  [blink]
+ */
+bool usubi_overflow_p (uint32_t a, uint32_t res)
+{
+  return __builtin_sub_overflow_p (a, 2000, res);
+}
+
+/* { dg-final { scan-assembler-times "sub.f\\s\+"   6 } } */
+/* { dg-final { scan-assembler-times "mov\.nv\\s\+" 4 } } */
+/* { dg-final { scan-assembler-times "setlo\\s\+"   2 } } */
+/* { dg-final { scan-assembler-times 

[PATCH 1/2] ARC: Use intrinsics for __builtin_add_overflow*()

2023-09-06 Thread Shahab Vahedi via Gcc-patches
This patch covers signed and unsigned additions.  The generated code
would be something along these lines:

signed:
  add.f   r0, r1, r2
  b.v @label

unsigned:
  add.f   r0, r1, r2
  b.c @label

gcc/ChangeLog:

* config/arc/arc-modes.def: Add CC_V mode.
* config/arc/predicates.md (proper_comparison_operator): Handle
E_CC_Vmode.
(equality_comparison_operator): Exclude CC_Vmode from eq/ne.
(cc_set_register): Handle CC_Vmode.
(cc_use_register): Likewise.
* config/arc/arc.md (addsi3_v): New insn.
(addvsi4): New expand.
(addsi3_c): New insn.
(uaddvsi4): New expand.
* config/arc/arc-protos.h (arc_gen_unlikely_cbranch): New.
* config/arc/arc.cc (arc_gen_unlikely_cbranch): New.
(get_arc_condition_code): Handle E_CC_Vmode.
(arc_init_reg_tables): Handle CC_Vmode.

gcc/testsuite/ChangeLog:

* gcc.target/arc/overflow-1.c: New.

Signed-off-by: Shahab Vahedi 
---
 gcc/config/arc/arc-modes.def  |   1 +
 gcc/config/arc/arc-protos.h   |   1 +
 gcc/config/arc/arc.cc |  26 +-
 gcc/config/arc/arc.md |  49 +++
 gcc/config/arc/predicates.md  |  14 ++-
 gcc/testsuite/gcc.target/arc/overflow-1.c | 100 ++
 6 files changed, 187 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/arc/overflow-1.c

diff --git a/gcc/config/arc/arc-modes.def b/gcc/config/arc/arc-modes.def
index 763e880317d..69eeec5935a 100644
--- a/gcc/config/arc/arc-modes.def
+++ b/gcc/config/arc/arc-modes.def
@@ -24,6 +24,7 @@ along with GCC; see the file COPYING3.  If not see
 
 CC_MODE (CC_ZN);
 CC_MODE (CC_Z);
+CC_MODE (CC_V);
 CC_MODE (CC_C);
 CC_MODE (CC_FP_GT);
 CC_MODE (CC_FP_GE);
diff --git a/gcc/config/arc/arc-protos.h b/gcc/config/arc/arc-protos.h
index 4f2db7ffb59..bc78fb0b370 100644
--- a/gcc/config/arc/arc-protos.h
+++ b/gcc/config/arc/arc-protos.h
@@ -50,6 +50,7 @@ extern bool arc_check_mov_const (HOST_WIDE_INT );
 extern bool arc_split_mov_const (rtx *);
 extern bool arc_can_use_return_insn (void);
 extern bool arc_split_move_p (rtx *);
+extern void arc_gen_unlikely_cbranch (enum rtx_code, machine_mode, rtx);
 #endif /* RTX_CODE */
 
 extern bool arc_ccfsm_branch_deleted_p (void);
diff --git a/gcc/config/arc/arc.cc b/gcc/config/arc/arc.cc
index f8c9bf17e2c..ec93d40aeb9 100644
--- a/gcc/config/arc/arc.cc
+++ b/gcc/config/arc/arc.cc
@@ -1538,6 +1538,13 @@ get_arc_condition_code (rtx comparison)
case GEU : return ARC_CC_NC;
default : gcc_unreachable ();
}
+case E_CC_Vmode:
+  switch (GET_CODE (comparison))
+   {
+   case EQ : return ARC_CC_NV;
+   case NE : return ARC_CC_V;
+   default : gcc_unreachable ();
+   }
 case E_CC_FP_GTmode:
   if (TARGET_ARGONAUT_SET && TARGET_SPFP)
switch (GET_CODE (comparison))
@@ -1868,7 +1875,7 @@ arc_init_reg_tables (void)
  /* mode_class hasn't been initialized yet for EXTRA_CC_MODES, so
 we must explicitly check for them here.  */
  if (i == (int) CCmode || i == (int) CC_ZNmode || i == (int) CC_Zmode
- || i == (int) CC_Cmode
+ || i == (int) CC_Cmode || i == (int) CC_Vmode
  || i == CC_FP_GTmode || i == CC_FP_GEmode || i == CC_FP_ORDmode
  || i == CC_FPUmode || i == CC_FPUEmode || i == CC_FPU_UNEQmode)
arc_mode_class[i] = 1 << (int) C_MODE;
@@ -11852,6 +11859,23 @@ arc_libm_function_max_error (unsigned cfn, 
machine_mode mode,
   return default_libm_function_max_error (cfn, mode, boundary_p);
 }
 
+/* Generate RTL for conditional branch with rtx comparison CODE in mode
+   CC_MODE.  */
+
+void
+arc_gen_unlikely_cbranch (enum rtx_code cmp, machine_mode cc_mode, rtx label)
+{
+  rtx cc_reg, x;
+
+  cc_reg = gen_rtx_REG (cc_mode, CC_REG);
+  label = gen_rtx_LABEL_REF (VOIDmode, label);
+
+  x = gen_rtx_fmt_ee (cmp, VOIDmode, cc_reg, const0_rtx);
+  x = gen_rtx_IF_THEN_ELSE (VOIDmode, x, label, pc_rtx);
+
+  emit_unlikely_jump (gen_rtx_SET (pc_rtx, x));
+}
+
 #undef TARGET_USE_ANCHORS_FOR_SYMBOL_P
 #define TARGET_USE_ANCHORS_FOR_SYMBOL_P arc_use_anchors_for_symbol_p
 
diff --git a/gcc/config/arc/arc.md b/gcc/config/arc/arc.md
index d37ecbf4292..9d011f6b4a9 100644
--- a/gcc/config/arc/arc.md
+++ b/gcc/config/arc/arc.md
@@ -2725,6 +2725,55 @@ archs4x, archs4xd"
  }
   ")
 
+(define_insn "addsi3_v"
+ [(set (match_operand:SI 0 "register_operand"  "=r,r,r,  r")
+   (plus:SI (match_operand:SI 1 "register_operand"   "r,r,0,  r")
+   (match_operand:SI 2 "nonmemory_operand"  "r,L,I,C32")))
+  (set (reg:CC_V CC_REG)
+   (compare:CC_V (sign_extend:DI (plus:SI (match_dup 1)
+ (match_dup 2)))
+(plus:DI (sign_extend:DI (match_dup 1))
+ (sign_extend:DI (match_dup 2)]
+ ""
+ "add.f\\t%0,%1,%2"
+ [(set_attr 

[PATCH] RISC-V: Fix VSETVL PASS AVL/VL fetch bug[111295]

2023-09-06 Thread Juzhe-Zhong
Fix bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111295

PR target/111295

gcc/ChangeLog:

* config/riscv/riscv-vsetvl.cc (insert_vsetvl):

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/pr111295.c: New test.

---
 gcc/config/riscv/riscv-vsetvl.cc  |  3 +-
 .../gcc.target/riscv/rvv/autovec/pr111295.c   | 36 +++
 2 files changed, 37 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/pr111295.c

diff --git a/gcc/config/riscv/riscv-vsetvl.cc b/gcc/config/riscv/riscv-vsetvl.cc
index e7e5c14617e..dd9aeb32b56 100644
--- a/gcc/config/riscv/riscv-vsetvl.cc
+++ b/gcc/config/riscv/riscv-vsetvl.cc
@@ -721,8 +721,7 @@ insert_vsetvl (enum emit_type emit_type, rtx_insn *rinsn,
   gcc_assert (has_vtype_op (rinsn) || vsetvl_insn_p (rinsn));
   /* For user vsetvli a5, zero, we should use get_vl to get the VL
 operand "a5".  */
-  rtx vl_op
-   = vsetvl_insn_p (rinsn) ? get_vl (rinsn) : info.get_avl_reg_rtx ();
+  rtx vl_op = info.get_avl_or_vl_reg ();
   gcc_assert (!vlmax_avl_p (vl_op));
   emit_vsetvl_insn (VSETVL_NORMAL, emit_type, info, vl_op, rinsn);
   return VSETVL_NORMAL;
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr111295.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr111295.c
new file mode 100644
index 000..fa20a21338a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr111295.c
@@ -0,0 +1,36 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d -Ofast -ftree-vectorize 
--param=riscv-autovec-preference=scalable -Wno-implicit-function-declaration" } 
*/
+
+#include 
+int a, b, c, e, f, g, h, i, j, k;
+long l;
+int q ()
+{
+  int r ();
+  char *o, *d;
+  _Bool p = f;
+  while (g)
+{
+  int m, n;
+  for (; m <= n; m++)
+   *d++ = m;
+  k = 1;
+  if (e)
+   break;
+  switch (*o)
+   {
+   case 'N':
+ o++;
+ if (c)
+   if (h)
+ while (i)
+   {
+ s (-l, ~0);
+ t (j);
+ d = d + (a & 1000 ? u (r, 2) : b);
+   }
+   }
+  if (*o)
+   p ? s () : 0;
+}
+}
-- 
2.36.3



Re: [PATCH] LoongArch: Fix unintentional bash-ism in r14-3665.

2023-09-06 Thread Richard Sandiford via Gcc-patches
Yang Yujie  writes:
> gcc/ChangeLog:
>
>   * config.gcc: remove non-POSIX syntax "<<<".

OK.  Thanks for the quick fix.

Richard.

> ---
>  gcc/config.gcc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index b2fe7c7ceef..6d4c8becd28 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -5189,7 +5189,7 @@ case "${target}" in
>   if test x${parse_state} = x"abi-base"; then
>   # Base ABI type
>   case ${component} in
> - lp64d | lp64f | lp64s) 
> elem_tmp="ABI_BASE_$(tr a-z A-Z <<< ${component}),";;
> + lp64d | lp64f | lp64s) 
> elem_tmp="ABI_BASE_$(echo ${component} | tr a-z A-Z),";;
>   *)
>   echo "Unknown base ABI 
> \"${component}\" in --with-multilib-list." 1>&2
>   exit 1


[PATCH] RISC-V: Remove unreasonable TARGET_64BIT for VLS modes with size = 64bit

2023-09-06 Thread Juzhe-Zhong
Previously,  I add TARGET_64BIT condtion to block VLS modes with size = 64bit 
in RV32 system
E.g. V8QI

Since I realized such modes may cause inferior codegen for some situations in 
RV32 system.

However, this is really quite ugly and it cause ICE for some cases in RV32:

FAIL: gcc.target/riscv/rvv/autovec/conversions/vfncvt-ftoi-run.c (internal 
compiler error: in require, at machmode.h:313)
3937FAIL: gcc.target/riscv/rvv/autovec/conversions/vfncvt-ftoi-run.c (test for 
excess errors)

For inferior codegen in RV32 system, we should try another reasonable approach 
to fix it.

Remove those TARGET_64BIT and fix ICE.

gcc/ChangeLog:

* config/riscv/riscv-vector-switch.def (VLS_ENTRY): Remove TARGET_64BIT

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/partial/slp-9.c: Adapt test.
* gcc.target/riscv/rvv/autovec/zve32f_zvl1024b-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve32f_zvl128b-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve32f_zvl2048b-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve32f_zvl256b-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve32f_zvl4096b-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve32f_zvl512b-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve32x_zvl1024b-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve32x_zvl128b-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve32x_zvl2048b-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve32x_zvl256b-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve32x_zvl4096b-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve32x_zvl512b-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve64d-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve64f-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve64x-1.c: Ditto.

---
 gcc/config/riscv/riscv-vector-switch.def  | 8 
 .../gcc.target/riscv/rvv/autovec/partial/slp-9.c  | 2 +-
 .../gcc.target/riscv/rvv/autovec/zve32f_zvl1024b-1.c  | 2 +-
 .../gcc.target/riscv/rvv/autovec/zve32f_zvl128b-1.c   | 2 +-
 .../gcc.target/riscv/rvv/autovec/zve32f_zvl2048b-1.c  | 2 +-
 .../gcc.target/riscv/rvv/autovec/zve32f_zvl256b-1.c   | 2 +-
 .../gcc.target/riscv/rvv/autovec/zve32f_zvl4096b-1.c  | 2 +-
 .../gcc.target/riscv/rvv/autovec/zve32f_zvl512b-1.c   | 2 +-
 .../gcc.target/riscv/rvv/autovec/zve32x_zvl1024b-1.c  | 2 +-
 .../gcc.target/riscv/rvv/autovec/zve32x_zvl128b-1.c   | 2 +-
 .../gcc.target/riscv/rvv/autovec/zve32x_zvl2048b-1.c  | 2 +-
 .../gcc.target/riscv/rvv/autovec/zve32x_zvl256b-1.c   | 2 +-
 .../gcc.target/riscv/rvv/autovec/zve32x_zvl4096b-1.c  | 2 +-
 .../gcc.target/riscv/rvv/autovec/zve32x_zvl512b-1.c   | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64d-1.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64f-1.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64x-1.c | 2 +-
 17 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/gcc/config/riscv/riscv-vector-switch.def 
b/gcc/config/riscv/riscv-vector-switch.def
index c035dc3558b..174e5a181c6 100644
--- a/gcc/config/riscv/riscv-vector-switch.def
+++ b/gcc/config/riscv/riscv-vector-switch.def
@@ -309,7 +309,7 @@ VLS_ENTRY (V4096BI, TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 
4096)
 VLS_ENTRY (V1QI, TARGET_VECTOR_VLS)
 VLS_ENTRY (V2QI, TARGET_VECTOR_VLS)
 VLS_ENTRY (V4QI, TARGET_VECTOR_VLS)
-VLS_ENTRY (V8QI, TARGET_VECTOR_VLS && TARGET_64BIT)
+VLS_ENTRY (V8QI, TARGET_VECTOR_VLS)
 VLS_ENTRY (V16QI, TARGET_VECTOR_VLS)
 VLS_ENTRY (V32QI, TARGET_VECTOR_VLS)
 VLS_ENTRY (V64QI, TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 64)
@@ -321,7 +321,7 @@ VLS_ENTRY (V2048QI, TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 
2048)
 VLS_ENTRY (V4096QI, TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 4096)
 VLS_ENTRY (V1HI, TARGET_VECTOR_VLS)
 VLS_ENTRY (V2HI, TARGET_VECTOR_VLS)
-VLS_ENTRY (V4HI, TARGET_VECTOR_VLS && TARGET_64BIT)
+VLS_ENTRY (V4HI, TARGET_VECTOR_VLS)
 VLS_ENTRY (V8HI, TARGET_VECTOR_VLS)
 VLS_ENTRY (V16HI, TARGET_VECTOR_VLS)
 VLS_ENTRY (V32HI, TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 64)
@@ -332,7 +332,7 @@ VLS_ENTRY (V512HI, TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 
1024)
 VLS_ENTRY (V1024HI, TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 2048)
 VLS_ENTRY (V2048HI, TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 4096)
 VLS_ENTRY (V1SI, TARGET_VECTOR_VLS)
-VLS_ENTRY (V2SI, TARGET_VECTOR_VLS && TARGET_64BIT)
+VLS_ENTRY (V2SI, TARGET_VECTOR_VLS)
 VLS_ENTRY (V4SI, TARGET_VECTOR_VLS)
 VLS_ENTRY (V8SI, TARGET_VECTOR_VLS)
 VLS_ENTRY (V16SI, TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 64)
@@ -342,7 +342,7 @@ VLS_ENTRY (V128SI, TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 
512)
 VLS_ENTRY (V256SI, TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 1024)
 VLS_ENTRY (V512SI, TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 2048)
 VLS_ENTRY (V1024SI, TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 4096)
-VLS_ENTRY (V1DI, TARGET_VECTOR_VLS && TARGET_VECTOR_ELEN_64 && TARGET_64BIT)
+VLS_ENTRY (V1DI, TARGET_VECTOR_VLS && TARGET_VECTOR_ELEN_64)
 

Re: [RFC] GCC Security policy

2023-09-06 Thread Siddhesh Poyarekar

Hello folks,

Here's v3 of the top part of the security policy.  Hopefully this 
addresses all concerns raised so far.


Thanks,
Sid


What is a GCC security bug?
===

A security bug is one that threatens the security of a system or
network, or might compromise the security of data stored on it.
In the context of GCC there are multiple ways in which this might
happen and they're detailed below.

Compiler drivers, programs, libgccjit and support libraries
---

The compiler driver processes source code, invokes other programs
such as the assembler and linker and generates the output result,
which may be assembly code or machine code.  Compiling untrusted
sources can result in arbitrary code execution and unconstrained
resource consumption in the compiler. As a result, compilation of
such code should be done inside a sandboxed environment to ensure
that it does not compromise the development environment.

The libgccjit library can, despite the name, be used both for
ahead-of-time compilation and for just-in-compilation.  In both
cases it can be used to translate input representations (such as
source code) in the application context; in the latter case the
generated code is also run in the application context.

Limitations that apply to the compiler driver, apply here too in
terms of sanitizing inputs and it is recommended that both the
compilation *and* execution context of the code are appropriately
sandboxed to contain the effects of any bugs in libgccjit, the
application code using it, or its generated code to the sandboxed
environment.

Support libraries such as libiberty, libcc1 libvtv and libcpp have
been developed separately to share code with other tools such as
binutils and gdb.  These libraries again have similar challenges to
compiler drivers.  While they are expected to be robust against
arbitrary input, they should only be used with trusted inputs.

Libraries such as zlib that bundled into GCC to build it will be
treated the same as the compiler drivers and programs as far as
security coverage is concerned.  However if you find an issue in
these libraries independent of their use in GCC, you should reach
out to their upstream projects to report them.

As a result, the only case for a potential security issue in the
compiler is when it generates vulnerable application code for
trusted input source code that is conforming to the relevant
programming standard or extensions documented as supported by GCC
and the algorithm expressed in the source code does not have the
vulnerability.  The output application code could be considered
vulnerable if it produces an actual vulnerability in the target
application, specifically in the following cases:

- The application dereferences an invalid memory location despite
  the application sources being valid.
- The application reads from or writes to a valid but incorrect
  memory location, resulting in an information integrity issue or an
  information leak.
- The application ends up running in an infinite loop or with
  severe degradation in performance despite the input sources having
  no such issue, resulting in a Denial of Service.  Note that
  correct but non-performant code is not a security issue candidate,
  this only applies to incorrect code that may result in performance
  degradation severe enough to amount to a denial of service.
- The application crashes due to the generated incorrect code,
  resulting in a Denial of Service.

Language runtime libraries
--

GCC also builds and distributes libraries that are intended to be
used widely to implement runtime support for various programming
languages.  These include the following:

* libada
* libatomic
* libbacktrace
* libcc1
* libcody
* libcpp
* libdecnumber
* libffi
* libgcc
* libgfortran
* libgm2
* libgo
* libgomp
* libiberty
* libitm
* libobjc
* libphobos
* libquadmath
* libsanitizer
* libssp
* libstdc++

These libraries are intended to be used in arbitrary contexts and as
a result, bugs in these libraries may be evaluated for security
impact.  However, some of these libraries, e.g. libgo, libphobos,
etc.  are not maintained in the GCC project, due to which the GCC
project may not be the correct point of contact for them.  You are
encouraged to look at README files within those library directories
to locate the canonical security contact point for those projects
and include them in the report.  Once the issue is fixed in the
upstream project, the fix will be synced into GCC in a future
release.

Most security vulnerabilities in these runtime 

Re: [PATCH] fwprop: Allow UNARY_P and check register pressure.

2023-09-06 Thread Robin Dapp via Gcc-patches
Hi Richard,

I did some testing with the attached v2 that does not restrict to UNARY
anymore.  As feared ;) there is some more fallout that I'm detailing below.

On Power there is one guality fail (pr43051-1.c) that I would take
the liberty of ignoring for now.

On x86 there are four fails:

 - cond_op_addsubmuldiv__Float16-2.c: assembler error
   unsupported masking for `vmovsh'.  I guess that's a latent backend
   problem.

 - ifcvt-3.c, pr49095.c: Here we propagate into a compare.  Before, we had
   (cmp (reg/CC) 0) and now we have (cmp (plus (reg1 reg2) 0).
   That looks like a costing problem and can hopefully solveable by making
   the second compare more expensive, preventing the propagation.
   i386 costing (or every costing?) is brittle so that could well break other
   things. 

 - pr88873.c: This is interesting because even before this patch we
   propagated with different register classes (V2DF vs DI).  With the patch
   we check the register pressure, find the class NO_REGS for V2DF and
   abort (because the patch assumes NO_REGS = high pressure).  I'm thinking
   of keeping the old behavior for reg-reg propagations and only checking
   the pressure for more complex operations.

aarch64 has the most fails:

 - One guality fail (same as Power).
 - shrn-combine-[123].c as before.

 - A class of (hopefully, I only checked some) similar cases where we
   propagate an unspec_whilelo into an unspec_ptest.  Before we would only
   set a REG_EQUALS note.
   Before we managed to create a while_ultsivnx16bi_cc whereas now we have
   while_ultsivnx16bi and while_ultsivnx16bi_ptest that won't be combined.
   We create redundant whilelos and I'm not sure how to improve that. I
   guess a peephole is out of the question :)

 - pred-combine-and.c: Here the new propagation appears useful at first.
   We propagate a "vector mask and" into a while_ultsivnx4bi_ptest and the
   individual and registers remain live up to the propagation site (while
   being dead before the patch).
   With the registers dead, combine could create a single fcmgt before.
   Now it only manages a 2->2 combination because we still need the registers
   and end up with two fcmgts.
   The code is worse but this seems more bad luck than anything.

 - Addressing fails from before:  I looked into these and suspect all of
   them are a similar.
   What happens is that we have a poly_int offset that we shift, negate
   and then add to x0.  The result is used as load address.
   Before, we would pull (combine) the (plus x0 reg) into the load keeping
   the neg and shift.
   Now we propagate everything into a single (set (minus x0 offset)).
   The propagation itself seems worthwhile because we save one insn.
   However as we got rid of the base/offset split by lumping everything
   together, combine cannot pull the (plus) into the address load and
   we require an aarch64_split_add_offset.  This will emit the longer
   sequence of ashiftl and subtract.  The "base" address is x0 here so
   we cannot convert (minus x0 ...)) into neg.
   I didn't go through all of aarch64_split_add_offset.  I suppose we
   could re-add the separation of base/offset there but that might be
   a loss when the result is not used as an address. 
   
Again, all in all no fatal problems but pretty annoying :)  It's not much
but just gradually worse than with just UNARY.  Any idea on how/whether to
continue?

Regards
 Robin

gcc/ChangeLog:

* fwprop.cc (fwprop_propagation::profitable_p): Add unary
handling.
(fwprop_propagation::update_register_pressure): New function.
(fwprop_propagation::register_pressure_high_p): New function
(reg_single_def_for_src_p): Look through unary expressions.
(try_fwprop_subst_pattern): Check register pressure.
(forward_propagate_into): Call new function.
(fwprop_init): Init register pressure.
(fwprop_done): Clean up register pressure.
(fwprop_insn): Add comment.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/binop/vadd-vx-fwprop.c: New test.
---
 gcc/fwprop.cc | 359 +-
 .../riscv/rvv/autovec/binop/vadd-vx-fwprop.c  |  64 
 2 files changed, 419 insertions(+), 4 deletions(-)
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vadd-vx-fwprop.c

diff --git a/gcc/fwprop.cc b/gcc/fwprop.cc
index 0707a234726..ce6f5a74b00 100644
--- a/gcc/fwprop.cc
+++ b/gcc/fwprop.cc
@@ -36,6 +36,10 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-pass.h"
 #include "rtl-iter.h"
 #include "target.h"
+#include "dominance.h"
+
+#include "ira.h"
+#include "regpressure.h"
 
 /* This pass does simple forward propagation and simplification when an
operand of an insn can only come from a single def.  This pass uses
@@ -103,6 +107,10 @@ using namespace rtl_ssa;
 
 static int num_changes;
 
+/* Keep track of which registers already increased the pressure to avoid double
+   booking.  

Re: [PATCH] RISC-V: Keep vlmax vector operators in simple form until split1 pass

2023-09-06 Thread Lehua Ding

Committed, thanks Kito.

--
Best,
Lehua



Re: [PATCH v1 1/4] LoongArch: Add tests of -mstrict-align option.

2023-09-06 Thread Xi Ruoyao via Gcc-patches
On Wed, 2023-09-06 at 18:43 +0800, Xiaolong Chen wrote:
> gcc/testsuite/ChangeLog:
> 
> * gcc.target/loongarch/strict-align.c: New test.

A question: is there really a CPU model with LSX/LASX but without
unaligned access support?  If not I think we'd just reject -mstrict-
align -mlsx.

Currently Glibc assumes if LSX is available then unaligned access must
be available too.

> ---
>  gcc/testsuite/gcc.target/loongarch/strict-align.c | 13 +
>  1 file changed, 13 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.target/loongarch/strict-align.c
> 
> diff --git a/gcc/testsuite/gcc.target/loongarch/strict-align.c
> b/gcc/testsuite/gcc.target/loongarch/strict-align.c
> new file mode 100644
> index 000..bcad2b84f68
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/loongarch/strict-align.c
> @@ -0,0 +1,13 @@
> +/* { dg-do compile } */
> +/* { dg-options "-Ofast -mstrict-align -mlasx" } */
> +/* { dg-final { scan-assembler-not "vfadd.s" } } */
> +
> +void
> +foo (float* restrict x, float* restrict y)
> +{
> +  x[0] = x[0] + y[0];
> +  x[1] = x[1] + y[1];
> +  x[2] = x[2] + y[2];
> +  x[3] = x[3] + y[3];
> +}
> +

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University


Re: [PATCH] LoongArch: Fix unintentional bash-ism in r14-3665.

2023-09-06 Thread Sam James via Gcc-patches


Yang Yujie  writes:

> gcc/ChangeLog:
>
>   * config.gcc: remove non-POSIX syntax "<<<".
> ---

Thanks, I was just about to report this.

>  gcc/config.gcc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index b2fe7c7ceef..6d4c8becd28 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -5189,7 +5189,7 @@ case "${target}" in
>   if test x${parse_state} = x"abi-base"; then
>   # Base ABI type
>   case ${component} in
> - lp64d | lp64f | lp64s) 
> elem_tmp="ABI_BASE_$(tr a-z A-Z <<< ${component}),";;
> + lp64d | lp64f | lp64s) 
> elem_tmp="ABI_BASE_$(echo ${component} | tr a-z A-Z),";;
>   *)
>   echo "Unknown base ABI 
> \"${component}\" in --with-multilib-list." 1>&2
>   exit 1



Re: [PATCH] LoongArch: Use bstrins instruction for (a & ~mask) and (a & mask) | (b & ~mask) [PR111252]

2023-09-06 Thread Xi Ruoyao via Gcc-patches
Forgot to mention: I've bootstrapped and regtested this patch on
loongarch64-linux-gnu (with PR110939 patch applied to unbreak the
bootstrapping).  Ok for trunk?

On Wed, 2023-09-06 at 18:46 +0800, Xi Ruoyao wrote:

> If mask is a constant with value ((1 << N) - 1) << M we can perform this
> optimization.
> 
> gcc/ChangeLog:
> 
> PR target/111252
> * config/loongarch/loongarch-protos.h
> (loongarch_pre_reload_split): Declare new function.
> (loongarch_use_bstrins_for_ior_with_mask): Likewise.
> * config/loongarch/loongarch.cc
> (loongarch_pre_reload_split): Implement.
> (loongarch_use_bstrins_for_ior_with_mask): Likewise.
> * config/loongarch/predicates.md (ins_zero_bitmask_operand):
> New predicate.
> * config/loongarch/loongarch.md (bstrins__for_mask):
> New define_insn_and_split.
> (bstrins__for_ior_mask): Likewise.
> (define_peephole2): Further optimize code sequence produced by
> bstrins__for_ior_mask if possible.
> 
> gcc/testsuite/ChangeLog:
> 
> * g++.target/loongarch/bstrins-compile.C: New test.
> * g++.target/loongarch/bstrins-run.C: New test.

/* snip */

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University


Re: [PATCH v1 4/4] LoongArch: Add tests for Loongson SX floating-point conversion instructions.

2023-09-06 Thread Xi Ruoyao via Gcc-patches
On Wed, 2023-09-06 at 18:45 +0800, Xiaolong Chen wrote:
> +  *((int*)& __m128_op0[3]) = 0x004200a0;
> +  *((int*)& __m128_op0[2]) = 0x;
> +  *((int*)& __m128_op0[1]) = 0x004200a0;
> +  *((int*)& __m128_op0[0]) = 0x0021;

These are aliasing rule violation and they will suddenly blow up when
GCC optimizer starts to optimize more aggressively based on the aliasing
rule.

Try not to use these (you can write a helper function to memcpy() into a
__m128).  Or use -fno-strict-alising in dg-options.

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University


[PATCH] LoongArch: Use bstrins instruction for (a & ~mask) and (a & mask) | (b & ~mask) [PR111252]

2023-09-06 Thread Xi Ruoyao via Gcc-patches
If mask is a constant with value ((1 << N) - 1) << M we can perform this
optimization.

gcc/ChangeLog:

PR target/111252
* config/loongarch/loongarch-protos.h
(loongarch_pre_reload_split): Declare new function.
(loongarch_use_bstrins_for_ior_with_mask): Likewise.
* config/loongarch/loongarch.cc
(loongarch_pre_reload_split): Implement.
(loongarch_use_bstrins_for_ior_with_mask): Likewise.
* config/loongarch/predicates.md (ins_zero_bitmask_operand):
New predicate.
* config/loongarch/loongarch.md (bstrins__for_mask):
New define_insn_and_split.
(bstrins__for_ior_mask): Likewise.
(define_peephole2): Further optimize code sequence produced by
bstrins__for_ior_mask if possible.

gcc/testsuite/ChangeLog:

* g++.target/loongarch/bstrins-compile.C: New test.
* g++.target/loongarch/bstrins-run.C: New test.
---
 gcc/config/loongarch/loongarch-protos.h   |  4 +-
 gcc/config/loongarch/loongarch.cc | 36 
 gcc/config/loongarch/loongarch.md | 91 +++
 gcc/config/loongarch/predicates.md|  8 ++
 .../g++.target/loongarch/bstrins-compile.C| 22 +
 .../g++.target/loongarch/bstrins-run.C| 65 +
 6 files changed, 225 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.target/loongarch/bstrins-compile.C
 create mode 100644 gcc/testsuite/g++.target/loongarch/bstrins-run.C

diff --git a/gcc/config/loongarch/loongarch-protos.h 
b/gcc/config/loongarch/loongarch-protos.h
index f4430d0d418..251011c5414 100644
--- a/gcc/config/loongarch/loongarch-protos.h
+++ b/gcc/config/loongarch/loongarch-protos.h
@@ -56,7 +56,7 @@ enum loongarch_symbol_type {
 };
 #define NUM_SYMBOL_TYPES (SYMBOL_TLSLDM + 1)
 
-/* Routines implemented in loongarch.c.  */
+/* Routines implemented in loongarch.cc.  */
 extern rtx loongarch_emit_move (rtx, rtx);
 extern HOST_WIDE_INT loongarch_initial_elimination_offset (int, int);
 extern void loongarch_expand_prologue (void);
@@ -163,6 +163,8 @@ extern const char *current_section_name (void);
 extern unsigned int current_section_flags (void);
 extern bool loongarch_use_ins_ext_p (rtx, HOST_WIDE_INT, HOST_WIDE_INT);
 extern bool loongarch_check_zero_div_p (void);
+extern bool loongarch_pre_reload_split (void);
+extern int loongarch_use_bstrins_for_ior_with_mask (machine_mode, rtx *);
 
 union loongarch_gen_fn_ptrs
 {
diff --git a/gcc/config/loongarch/loongarch.cc 
b/gcc/config/loongarch/loongarch.cc
index aeb37f0f2f7..6698414281e 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -5482,6 +5482,42 @@ loongarch_use_ins_ext_p (rtx op, HOST_WIDE_INT width, 
HOST_WIDE_INT bitpos)
   return true;
 }
 
+/* Predicate for pre-reload splitters with associated instructions,
+   which can match any time before the split1 pass (usually combine),
+   then are unconditionally split in that pass and should not be
+   matched again afterwards.  */
+
+bool loongarch_pre_reload_split (void)
+{
+  return (can_create_pseudo_p ()
+ && !(cfun->curr_properties & PROP_rtl_split_insns));
+}
+
+/* Check if we can use bstrins. for
+   op0 = (op1 & op2) | (op3 & op4)
+   where op0, op1, op3 are regs, and op2, op4 are integer constants.  */
+int
+loongarch_use_bstrins_for_ior_with_mask (machine_mode mode, rtx *op)
+{
+  unsigned HOST_WIDE_INT mask1 = UINTVAL (op[2]);
+  unsigned HOST_WIDE_INT mask2 = UINTVAL (op[4]);
+
+  if (mask1 != ~mask2 || !mask1 || !mask2)
+return 0;
+
+  /* Try to avoid a right-shift.  */
+  if (low_bitmask_len (mode, mask1) != -1)
+return -1;
+
+  if (low_bitmask_len (mode, mask2 >> (ffs_hwi (mask2) - 1)) != -1)
+return 1;
+
+  if (low_bitmask_len (mode, mask1 >> (ffs_hwi (mask1) - 1)) != -1)
+return -1;
+
+  return 0;
+}
+
 /* Print the text for PRINT_OPERAND punctation character CH to FILE.
The punctuation characters are:
 
diff --git a/gcc/config/loongarch/loongarch.md 
b/gcc/config/loongarch/loongarch.md
index 2308db16902..75f641b38ee 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -1322,6 +1322,97 @@ (define_insn "and3_extended"
   [(set_attr "move_type" "pick_ins")
(set_attr "mode" "")])
 
+(define_insn_and_split "*bstrins__for_mask"
+  [(set (match_operand:GPR 0 "register_operand")
+   (and:GPR (match_operand:GPR 1 "register_operand")
+(match_operand:GPR 2 "ins_zero_bitmask_operand")))]
+  ""
+  "#"
+  ""
+  [(set (match_dup 0) (match_dup 1))
+   (set (zero_extract:GPR (match_dup 0) (match_dup 2) (match_dup 3))
+   (const_int 0))]
+  {
+unsigned HOST_WIDE_INT mask = ~UINTVAL (operands[2]);
+int lo = ffs_hwi (mask) - 1;
+int len = low_bitmask_len (mode, mask >> lo);
+
+len = MIN (len, GET_MODE_BITSIZE (mode) - lo);
+operands[2] = GEN_INT (len);
+operands[3] = GEN_INT (lo);
+  })
+
+(define_insn_and_split "*bstrins__for_ior_mask"
+  

[PATCH v1 3/4] LoongArch: Add tests for Loongson SX builtin functions.

2023-09-06 Thread Xiaolong Chen
gcc/testsuite/ChangeLog:

* gcc.target/loongarch/vector/lsx/lsx-builtin.c: New test.
---
 .../loongarch/vector/lsx/lsx-builtin.c| 1461 +
 1 file changed, 1461 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-builtin.c

diff --git a/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-builtin.c 
b/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-builtin.c
new file mode 100644
index 000..70f5000b29f
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-builtin.c
@@ -0,0 +1,1461 @@
+/* Test builtins for LOONGARCH LSX ASE instructions */
+/* { dg-do compile } */
+/* { dg-options "-mlsx" } */
+/* { dg-final { scan-assembler-times "lsx_vsll_b:.*vsll\\.b.*lsx_vsll_b" 1 } } 
*/
+/* { dg-final { scan-assembler-times "lsx_vsll_h:.*vsll\\.h.*lsx_vsll_h" 1 } } 
*/
+/* { dg-final { scan-assembler-times "lsx_vsll_w:.*vsll\\.w.*lsx_vsll_w" 1 } } 
*/
+/* { dg-final { scan-assembler-times "lsx_vsll_d:.*vsll\\.d.*lsx_vsll_d" 1 } } 
*/
+/* { dg-final { scan-assembler-times "lsx_vslli_b:.*vslli\\.b.*lsx_vslli_b" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vslli_h:.*vslli\\.h.*lsx_vslli_h" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vslli_w:.*vslli\\.w.*lsx_vslli_w" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vslli_d:.*vslli\\.d.*lsx_vslli_d" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsra_b:.*vsra\\.b.*lsx_vsra_b" 1 } } 
*/
+/* { dg-final { scan-assembler-times "lsx_vsra_h:.*vsra\\.h.*lsx_vsra_h" 1 } } 
*/
+/* { dg-final { scan-assembler-times "lsx_vsra_w:.*vsra\\.w.*lsx_vsra_w" 1 } } 
*/
+/* { dg-final { scan-assembler-times "lsx_vsra_d:.*vsra\\.d.*lsx_vsra_d" 1 } } 
*/
+/* { dg-final { scan-assembler-times "lsx_vsrai_b:.*vsrai\\.b.*lsx_vsrai_b" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrai_h:.*vsrai\\.h.*lsx_vsrai_h" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrai_w:.*vsrai\\.w.*lsx_vsrai_w" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrai_d:.*vsrai\\.d.*lsx_vsrai_d" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrar_b:.*vsrar\\.b.*lsx_vsrar_b" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrar_h:.*vsrar\\.h.*lsx_vsrar_h" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrar_w:.*vsrar\\.w.*lsx_vsrar_w" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrar_d:.*vsrar\\.d.*lsx_vsrar_d" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrari_b:.*vsrari\\.b.*lsx_vsrari_b" 
1 } } */
+/* { dg-final { scan-assembler-times "lsx_vsrari_h:.*vsrari\\.h.*lsx_vsrari_h" 
1 } } */
+/* { dg-final { scan-assembler-times "lsx_vsrari_w:.*vsrari\\.w.*lsx_vsrari_w" 
1 } } */
+/* { dg-final { scan-assembler-times "lsx_vsrari_d:.*vsrari\\.d.*lsx_vsrari_d" 
1 } } */
+/* { dg-final { scan-assembler-times "lsx_vsrl_b:.*vsrl\\.b.*lsx_vsrl_b" 1 } } 
*/
+/* { dg-final { scan-assembler-times "lsx_vsrl_h:.*vsrl\\.h.*lsx_vsrl_h" 1 } } 
*/
+/* { dg-final { scan-assembler-times "lsx_vsrl_w:.*vsrl\\.w.*lsx_vsrl_w" 1 } } 
*/
+/* { dg-final { scan-assembler-times "lsx_vsrl_d:.*vsrl\\.d.*lsx_vsrl_d" 1 } } 
*/
+/* { dg-final { scan-assembler-times "lsx_vsrli_b:.*vsrli\\.b.*lsx_vsrli_b" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrli_h:.*vsrli\\.h.*lsx_vsrli_h" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrli_w:.*vsrli\\.w.*lsx_vsrli_w" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrli_d:.*vsrli\\.d.*lsx_vsrli_d" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrlr_b:.*vsrlr\\.b.*lsx_vsrlr_b" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrlr_h:.*vsrlr\\.h.*lsx_vsrlr_h" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrlr_w:.*vsrlr\\.w.*lsx_vsrlr_w" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrlr_d:.*vsrlr\\.d.*lsx_vsrlr_d" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrlri_b:.*vsrlri\\.b.*lsx_vsrlri_b" 
1 } } */
+/* { dg-final { scan-assembler-times "lsx_vsrlri_h:.*vsrlri\\.h.*lsx_vsrlri_h" 
1 } } */
+/* { dg-final { scan-assembler-times "lsx_vsrlri_w:.*vsrlri\\.w.*lsx_vsrlri_w" 
1 } } */
+/* { dg-final { scan-assembler-times "lsx_vsrlri_d:.*vsrlri\\.d.*lsx_vsrlri_d" 
1 } } */
+/* { dg-final { scan-assembler-times 
"lsx_vbitclr_b:.*vbitclr\\.b.*lsx_vbitclr_b" 1 } } */
+/* { dg-final { scan-assembler-times 
"lsx_vbitclr_h:.*vbitclr\\.h.*lsx_vbitclr_h" 1 } } */
+/* { dg-final { scan-assembler-times 
"lsx_vbitclr_w:.*vbitclr\\.w.*lsx_vbitclr_w" 1 } } */
+/* { dg-final { scan-assembler-times 
"lsx_vbitclr_d:.*vbitclr\\.d.*lsx_vbitclr_d" 1 } } */
+/* { dg-final { scan-assembler-times 
"lsx_vbitclri_b:.*vbitclri\\.b.*lsx_vbitclri_b" 1 } } */
+/* { dg-final { scan-assembler-times 
"lsx_vbitclri_h:.*vbitclri\\.h.*lsx_vbitclri_h" 1 } } */
+/* { dg-final { scan-assembler-times 
"lsx_vbitclri_w:.*vbitclri\\.w.*lsx_vbitclri_w" 1 } } */
+/* { dg-final { scan-assembler-times 
"lsx_vbitclri_d:.*vbitclri\\.d.*lsx_vbitclri_d" 1 } } */
+/* { dg-final { scan-assembler-times 
"lsx_vbitset_b:.*vbitset\\.b.*lsx_vbitset_b" 1 } } 

[PATCH v1 2/4] LoongArch: Add testsuite framework for Loongson SX/ASX.

2023-09-06 Thread Xiaolong Chen
gcc/testsuite/ChangeLog:

* gcc.target/loongarch/vector/loongarch-vector.exp: New test.
* gcc.target/loongarch/vector/simd_correctness_check.h: New test.
---
 .../loongarch/vector/loongarch-vector.exp | 42 +++
 .../loongarch/vector/simd_correctness_check.h | 39 +
 2 files changed, 81 insertions(+)
 create mode 100644 
gcc/testsuite/gcc.target/loongarch/vector/loongarch-vector.exp
 create mode 100644 
gcc/testsuite/gcc.target/loongarch/vector/simd_correctness_check.h

diff --git a/gcc/testsuite/gcc.target/loongarch/vector/loongarch-vector.exp 
b/gcc/testsuite/gcc.target/loongarch/vector/loongarch-vector.exp
new file mode 100644
index 000..b0616a26b0e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vector/loongarch-vector.exp
@@ -0,0 +1,42 @@
+# Copyright (C) 2021-2023 Free Software Foundation, Inc.
+
+# This program 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 of the License, or
+# (at your option) any later version.
+#
+# This program 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
+# .
+
+# GCC testsuite that uses the `dg.exp' driver.
+
+# Exit immediately if this isn't a LoongArch target.
+if ![istarget loongarch*-*-*] then {
+  return
+}
+
+# Load support procs.
+load_lib gcc-dg.exp
+
+# If a testcase doesn't have special options, use these.
+global DEFAULT_CFLAGS
+if ![info exists DEFAULT_CFLAGS] then {
+set DEFAULT_CFLAGS " -mlasx"
+}
+
+# Initialize `dg'.
+dg-init
+
+# Main loop.
+dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/lsx/*.\[cS\]]] \
+   "" $DEFAULT_CFLAGS
+dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/lasx/*.\[cS\]]] \
+   "" $DEFAULT_CFLAGS
+# All done.
+dg-finish
diff --git a/gcc/testsuite/gcc.target/loongarch/vector/simd_correctness_check.h 
b/gcc/testsuite/gcc.target/loongarch/vector/simd_correctness_check.h
new file mode 100644
index 000..7be199ee3a0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vector/simd_correctness_check.h
@@ -0,0 +1,39 @@
+#include 
+#include 
+#include 
+
+#define ASSERTEQ_64(line, ref, res)
\
+do{
\
+int fail = 0;  
\
+for(size_t i = 0; i < sizeof(res)/sizeof(res[0]); ++i){
\
+   long *temp_ref = [i], *temp_res = [i];  
\
+   if(abs(*temp_ref - *temp_res) > 0){ 
\
+   printf(" error: %s at line %ld , expected "#ref"[%ld]:0x%lx, got: 
0x%lx\n", \
+   __FILE__, line, i, *temp_ref, *temp_res);   
\
+   fail = 1;   
\
+   }   
\
+}  
\
+if(fail == 1) abort(); 
\
+}while(0) 
+
+#define ASSERTEQ_32(line, ref, res)
\
+do{
\
+int fail = 0;  
\
+for(size_t i = 0; i < sizeof(res)/sizeof(res[0]); ++i){
\
+   int *temp_ref = [i], *temp_res = [i];   
\
+   if(abs(*temp_ref - *temp_res) > 0){ 
\
+   printf(" error: %s at line %ld , expected "#ref"[%ld]:0x%x, got: 
0x%x\n",   \
+  __FILE__, line, i, *temp_ref, *temp_res);
\
+   fail = 1;   
\
+   }   
\
+}  
\
+if(fail == 1) abort(); 
\
+}while(0) 
+
+#define ASSERTEQ_int(line, ref, res)   
\
+do{
\
+if (ref != res){   
\
+   printf(" 

[PATCH v1 1/4] LoongArch: Add tests of -mstrict-align option.

2023-09-06 Thread Xiaolong Chen
gcc/testsuite/ChangeLog:

* gcc.target/loongarch/strict-align.c: New test.
---
 gcc/testsuite/gcc.target/loongarch/strict-align.c | 13 +
 1 file changed, 13 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/strict-align.c

diff --git a/gcc/testsuite/gcc.target/loongarch/strict-align.c 
b/gcc/testsuite/gcc.target/loongarch/strict-align.c
new file mode 100644
index 000..bcad2b84f68
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/strict-align.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-Ofast -mstrict-align -mlasx" } */
+/* { dg-final { scan-assembler-not "vfadd.s" } } */
+
+void
+foo (float* restrict x, float* restrict y)
+{
+  x[0] = x[0] + y[0];
+  x[1] = x[1] + y[1];
+  x[2] = x[2] + y[2];
+  x[3] = x[3] + y[3];
+}
+
-- 
2.20.1



[PATCH v1 0/4] Add Loongson SX/ASX instruction support to LoongArch

2023-09-06 Thread Xiaolong Chen
In order to better test the function of the vector instruction, the 128 and 256 
bit test cases are further split according to the function of the instruction.

Xiaolong Chen (4):
  LoongArch: Add tests of -mstrict-align option.
  LoongArch: Add testsuite framework for Loongson SX/ASX.
  LoongArch: Add tests for Loongson SX builtin functions.
  LoongArch: Add tests for Loongson SX floating-point conversion
instructions.

 .../gcc.target/loongarch/strict-align.c   |   13 +
 .../loongarch/vector/loongarch-vector.exp |   42 +
 .../loongarch/vector/lsx/lsx-builtin.c| 1461 +
 .../loongarch/vector/lsx/lsx-vfcvt-1.c|  397 +
 .../loongarch/vector/lsx/lsx-vfcvt-2.c|  277 
 .../loongarch/vector/lsx/lsx-vffint-1.c   |  160 ++
 .../loongarch/vector/lsx/lsx-vffint-2.c   |  263 +++
 .../loongarch/vector/lsx/lsx-vffint-3.c   |  101 ++
 .../loongarch/vector/lsx/lsx-vfrint_d.c   |  229 +++
 .../loongarch/vector/lsx/lsx-vfrint_s.c   |  349 
 .../loongarch/vector/lsx/lsx-vftint-1.c   |  348 
 .../loongarch/vector/lsx/lsx-vftint-2.c   |  694 
 .../loongarch/vector/lsx/lsx-vftint-3.c   | 1027 
 .../loongarch/vector/lsx/lsx-vftint-4.c   |  344 
 .../loongarch/vector/simd_correctness_check.h |   39 +
 15 files changed, 5744 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/strict-align.c
 create mode 100644 
gcc/testsuite/gcc.target/loongarch/vector/loongarch-vector.exp
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-builtin.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfcvt-1.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfcvt-2.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vffint-1.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vffint-2.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vffint-3.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfrint_d.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfrint_s.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vftint-1.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vftint-2.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vftint-3.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vftint-4.c
 create mode 100644 
gcc/testsuite/gcc.target/loongarch/vector/simd_correctness_check.h

-- 
2.20.1



Re: [PATCH] LoongArch: Link c++ header directory in the default ABI to the toplevel.

2023-09-06 Thread Xi Ruoyao via Gcc-patches
On Wed, 2023-09-06 at 18:06 +0800, Yang Yujie wrote:
> When multilib is enabled, the c++ header directory of the default multilib
> variant needs to be linked to the toplevel since g++ does not search the
> toplevel in this case.
> 
> libstdc++-v3/ChangeLog:
> 
> * configure.host: Register t-loongarch in tmake_file.
> * config/cpu/loongarch/t-loongarch: New file.  Link c++ header
> directory in the default ABI to the toplevel.
> ---
>  libstdc++-v3/config/cpu/loongarch/t-loongarch | 12 
>  libstdc++-v3/configure.host   |  5 -
>  2 files changed, 16 insertions(+), 1 deletion(-)
>  create mode 100644 libstdc++-v3/config/cpu/loongarch/t-loongarch
> 
> diff --git a/libstdc++-v3/config/cpu/loongarch/t-loongarch
> b/libstdc++-v3/config/cpu/loongarch/t-loongarch
> new file mode 100644
> index 000..942eddeb3be
> --- /dev/null
> +++ b/libstdc++-v3/config/cpu/loongarch/t-loongarch
> @@ -0,0 +1,12 @@
> +LA_DEFAULT_MULTIDIR = $(shell $(CXX) --print-multi-directory)
> +TOPLEV_HEADERS = 
> $(DESTDIR)${gxx_include_dir}/${host_alias}/$(LA_DEFAULT_MULTIDIR)
> +
> +.PHONY: install-toplevel-link
> +install: install-toplevel-link
> +install-toplevel-link:
> +   if test x$(MULTIDO) != xtrue && \
> +  test x$(LA_DEFAULT_MULTIDIR) != x.; then \
> +   $(MKDIR_P) "$(dir $(TOPLEV_HEADERS))"; \
> +   rm -rf "$(TOPLEV_HEADERS)"; \
> +   $(LN_S) ../ "$(TOPLEV_HEADERS)"; \

>From autoconf info page:

 -- Macro: AC_PROG_LN_S
 If ‘ln -s’ works on the current file system (the operating system
 and file system support symbolic links), set the output variable
 ‘LN_S’ to ‘ln -s’; otherwise, if ‘ln’ works, set ‘LN_S’ to ‘ln’,
 and otherwise set it to ‘cp -pR’.

 If you make a link in a directory other than the current directory,
 its meaning depends on whether ‘ln’ or ‘ln -s’ is used.  To safely
 create links using ‘$(LN_S)’, either find out which form is used
 and adjust the arguments, or always invoke ‘ln’ in the directory
 where the link is to be created.

 In other words, it does not work to do:
  $(LN_S) foo /x/bar

 Instead, do:

  (cd /x && $(LN_S) foo bar)

But for this special case we cannot "cp -pR ../ $(TOPLEV_HEADERS)"
either:

$ cp ../* -pR something
cp: cannot copy a directory, '../g', into itself, 'h/g'

So I guess we'll need something like

if ln -s ../ "$(TOPLEV_HEADERS)"; then
  # OK!
  true
else
  # system does not support symlink :(
  # install another copy of toplevel headers into default multilib subdir
  TODO: 
fi

And all libstdc++ patches should Cc: libstd...@gcc.gnu.org.

> +   fi
> diff --git a/libstdc++-v3/configure.host b/libstdc++-v3/configure.host
> index 9e7c7f02dfd..9dc42ad3edb 100644
> --- a/libstdc++-v3/configure.host
> +++ b/libstdc++-v3/configure.host
> @@ -315,7 +315,10 @@ esac
>  # Set any OS-dependent and CPU-dependent bits.
>  # THIS TABLE IS SORTED.  KEEP IT THAT WAY.
>  case "${host}" in
> -  *-*-linux* | *-*-uclinux*)
> + loongarch*)
> +    tmake_file="cpu/loongarch/t-loongarch"
> +    ;;
> + *-*-linux* | *-*-uclinux*)
>  case "${host_cpu}" in
>    i[567]86)
>  abi_baseline_pair=i486-linux-gnu

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University


Re: [PATCH] xtensa: Optimize boolean evaluation when SImode EQ/NE to zero if TARGET_MINMAX

2023-09-06 Thread Max Filippov via Gcc-patches
On Tue, Sep 5, 2023 at 2:29 AM Takayuki 'January June' Suwa
 wrote:
>
> This patch optimizes the boolean evaluation for equality to 0 in SImode
> using the MINU (Minimum Value Unsigned) machine instruction available
> when TARGET_MINMAX is configured, for example, (x != 0) to MINU(x, 1)
> and (x == 0) to (MINU(x, 1) ^ 1).
>
> /* example */
> int test0(int x) {
>   return x == 0;
> }
> int test1(int x) {
>   return x != 0;
> }
>
> ;; before
> test0:
> mov.n   a10, a2
> movi.n  a9, 1
> movi.n  a2, 0
> moveqz  a2, a9, a10
> ret.n
> test1:
> mov.n   a10, a2
> movi.n  a9, 1
> movi.n  a2, 0
> movnez  a2, a9, a10
> ret.n
>
> ;; after (prereq. TARGET_MINMAX)
> test0:
> movi.n  a9, 1
> minua2, a2, a9
> xor a2, a2, a9
> ret.n
> test1:
> movi.n  a9, 1
> minua2, a2, a9
> ret.n
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.cc (xtensa_expand_scc):
> Add code for particular constants (only 0 and INT_MIN for now)
> for EQ/NE boolean evaluation in SImode.
> * config/xtensa/xtensa.md (*eqne_INT_MIN): Remove because its
> implementation has been integrated into the above.
> ---
>  gcc/config/xtensa/xtensa.cc | 43 +++--
>  gcc/config/xtensa/xtensa.md | 34 -
>  2 files changed, 37 insertions(+), 40 deletions(-)

Regtested for target=xtensa-linux-uclibc, no new regressions.
Committed to master.

-- 
Thanks.
-- Max


Re: [PATCH] xtensa: Optimize boolean evaluation when SImode EQ/NE to zero if TARGET_MINMAX

2023-09-06 Thread Max Filippov via Gcc-patches
On Tue, Sep 5, 2023 at 9:24 PM Takayuki 'January June' Suwa
 wrote:
> On 2023/09/06 8:01, Max Filippov wrote:
> > On Tue, Sep 5, 2023 at 2:29 AM Takayuki 'January June' Suwa
> >  wrote:
> >> ;; after (prereq. TARGET_MINMAX)
> >> test0:
> >> movi.n  a9, 1
> >> minua2, a2, a9
> >> xor a2, a2, a9
> >> ret.n
> >
> > ISTM that test0 could be done with movnez in the same three instructions:
> >
> >   movi a9, 1
> >   movnez a2, a9, a2
> >   xor a2, a2, a9
>
> Unfortunately, the MOV[EQ/NE]Z machine instruction can only be used
> to implement the functionality if the input and output physical registers
> are the same (a2 in the example).

Oh yeah, you're right, I missed that.

-- 
Thanks.
-- Max


Re: [PATCH v5] c++: extend cold, hot attributes to classes

2023-09-06 Thread Javier Martinez via Gcc-patches
reminder: ready for commit?

- Javier

On Wed 23. Aug 2023 at 15:02, Javier Martinez <
javier.martinez.bugzi...@gmail.com> wrote:

> On Tue, Aug 22, 2023 at 7:50 PM Jason Merrill  wrote:
> > You still need an update to doc/extend.texi for this additional use of
> > the attribute.  Sorry I didn't think of that before.
>
> I should have caught that too, many thanks.
>
> Also addressed the formatting comments. Patch attached.
>
> Signed-off-by: Javier Martinez 
>


Re: [PATCH] riscv: xtheadbb: Fix xtheadbb-li-rotr test for rv32

2023-09-06 Thread Philipp Tomsich
Committed as "obvious" to master.
--Philipp.

On Wed, 6 Sept 2023 at 12:04, Christoph Muellner <
christoph.muell...@vrull.eu> wrote:

> From: Christoph Müllner 
>
> The test was introduced recently and tests a RV64-only feature.
> However, when testing an RV32 compiler, the test gets executed as well
> and fails with "cc1: error: ABI requires '-march=rv32'".
> This patch fixes this by adding '-mabi=lp64' (like it is done for
> other RV64-only tests as well).
>
> Retested with RV32 and RV64 to ensure this won't pop up again.
>
> Signed-off-by: Christoph Müllner 
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/xtheadbb-li-rotr.c: Don't run for RV32.
> ---
>  gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c
> b/gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c
> index 136dcb01cf4..01f4215179a 100644
> --- a/gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c
> +++ b/gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile } */
> -/* { dg-options "-march=rv64gc_xtheadbb" } */
> +/* { dg-options "-march=rv64gc_xtheadbb -mabi=lp64" } */
>  /* { dg-skip-if "" { *-*-* } {"-O0" "-Os" "-Og" "-Oz" "-flto" } } */
>  /* { dg-final { check-function-bodies "**" "" } } */
>
> --
> 2.41.0
>
>


[PATCH] LoongArch: Link c++ header directory in the default ABI to the toplevel.

2023-09-06 Thread Yang Yujie
When multilib is enabled, the c++ header directory of the default multilib
variant needs to be linked to the toplevel since g++ does not search the
toplevel in this case.

libstdc++-v3/ChangeLog:

* configure.host: Register t-loongarch in tmake_file.
* config/cpu/loongarch/t-loongarch: New file.  Link c++ header
directory in the default ABI to the toplevel.
---
 libstdc++-v3/config/cpu/loongarch/t-loongarch | 12 
 libstdc++-v3/configure.host   |  5 -
 2 files changed, 16 insertions(+), 1 deletion(-)
 create mode 100644 libstdc++-v3/config/cpu/loongarch/t-loongarch

diff --git a/libstdc++-v3/config/cpu/loongarch/t-loongarch 
b/libstdc++-v3/config/cpu/loongarch/t-loongarch
new file mode 100644
index 000..942eddeb3be
--- /dev/null
+++ b/libstdc++-v3/config/cpu/loongarch/t-loongarch
@@ -0,0 +1,12 @@
+LA_DEFAULT_MULTIDIR = $(shell $(CXX) --print-multi-directory)
+TOPLEV_HEADERS = 
$(DESTDIR)${gxx_include_dir}/${host_alias}/$(LA_DEFAULT_MULTIDIR)
+
+.PHONY: install-toplevel-link
+install: install-toplevel-link
+install-toplevel-link:
+   if test x$(MULTIDO) != xtrue && \
+  test x$(LA_DEFAULT_MULTIDIR) != x.; then \
+   $(MKDIR_P) "$(dir $(TOPLEV_HEADERS))"; \
+   rm -rf "$(TOPLEV_HEADERS)"; \
+   $(LN_S) ../ "$(TOPLEV_HEADERS)"; \
+   fi
diff --git a/libstdc++-v3/configure.host b/libstdc++-v3/configure.host
index 9e7c7f02dfd..9dc42ad3edb 100644
--- a/libstdc++-v3/configure.host
+++ b/libstdc++-v3/configure.host
@@ -315,7 +315,10 @@ esac
 # Set any OS-dependent and CPU-dependent bits.
 # THIS TABLE IS SORTED.  KEEP IT THAT WAY.
 case "${host}" in
-  *-*-linux* | *-*-uclinux*)
+ loongarch*)
+tmake_file="cpu/loongarch/t-loongarch"
+;;
+ *-*-linux* | *-*-uclinux*)
 case "${host_cpu}" in
   i[567]86)
 abi_baseline_pair=i486-linux-gnu
-- 
2.36.0



[PATCH] riscv: xtheadbb: Fix xtheadbb-li-rotr test for rv32

2023-09-06 Thread Christoph Muellner
From: Christoph Müllner 

The test was introduced recently and tests a RV64-only feature.
However, when testing an RV32 compiler, the test gets executed as well
and fails with "cc1: error: ABI requires '-march=rv32'".
This patch fixes this by adding '-mabi=lp64' (like it is done for
other RV64-only tests as well).

Retested with RV32 and RV64 to ensure this won't pop up again.

Signed-off-by: Christoph Müllner 

gcc/testsuite/ChangeLog:

* gcc.target/riscv/xtheadbb-li-rotr.c: Don't run for RV32.
---
 gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c 
b/gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c
index 136dcb01cf4..01f4215179a 100644
--- a/gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c
+++ b/gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-march=rv64gc_xtheadbb" } */
+/* { dg-options "-march=rv64gc_xtheadbb -mabi=lp64" } */
 /* { dg-skip-if "" { *-*-* } {"-O0" "-Os" "-Og" "-Oz" "-flto" } } */
 /* { dg-final { check-function-bodies "**" "" } } */
 
-- 
2.41.0



  1   2   >