LGTM for the patch
Li, Pan2 於 2024年2月21日 週三 12:31 寫道：
> Hi kito and juzhe.
>
> There may be 2 items for double-confirm. Thanks a lot.
>
> 1. Not very sure if we need to upgrade the version for
> __riscv_th_v_intrinsic.
>
Yes since 0.11 and 0.12 is not really compatible
2. Do we need to upgrad
Palmer Dabbelt 於 2024年2月22日 週四 07:42 寫道：
> On Wed, 21 Feb 2024 15:34:32 PST (-0800), Kito Cheng wrote:
> > LGTM for the patch
> >
> > Li, Pan2 於 2024年2月21日 週三 12:31 寫道：
> >
> >> Hi kito and juzhe.
> >>
> >> There may be 2 items for double-c
LGTM, but I am OoO today, will commit that once I have laptop :p
Fangrui Song 於 2024年2月22日 週四 05:54 寫道：
> On Tue, Feb 13, 2024 at 10:36 PM Fangrui Song wrote:
> >
> > The constraints "i" and "s" can be used with a symbol that binds
> > externally, e.g.
> > ```
> > namespace ns { extern int var,
LGTM, and committed :)
On Tue, Feb 20, 2024 at 11:46 PM Palmer Dabbelt wrote:
>
> This came up recently as Edwin was looking through the test suite. A
> few of us were talking about this during the patchwork meeting and were
> surprised. Looks like this is the desired behavior, so let's at leas
I guess Palmer is too busy, so committed to trunk :P
On Tue, Feb 13, 2024 at 11:55 PM Jeff Law wrote:
>
>
>
> On 2/9/24 09:53, Palmer Dabbelt wrote:
> > This builds for me, and I frequently have python-is-python3 type
> > packages installed so I think I've been implicitly testing it for a
> > whi
I would prefer to only keep zvl and scalable or zvl only, since I
don't see too much value in specifying a value which different from
zvl*b, that's a legacy option used before zvl*b option was introduced,
and the reason to add that is that could used for compatible with
clang/LLVM for riscv_rvv_vec
On Fri, Feb 23, 2024 at 3:48 AM Palmer Dabbelt wrote:
>
> On Wed, 21 Feb 2024 16:02:50 PST (-0800), Kito Cheng wrote:
> > Palmer Dabbelt 於 2024年2月22日 週四 07:42 寫道：
> >
> >> On Wed, 21 Feb 2024 15:34:32 PST (-0800), Kito Cheng wrote:
> >> > LGTM for the patch
Keep SCALABLE, since it has different semantics with ZVL:
-mrvv-vector-bits=scalble means zvl*b specify the minimal VLEN
-mrvv-vector-bits=zvl means zvl*b specify the exactly VLEN
What's difference exactly?
-mrvv-vector-bits=scalble with zvl128b can run on any machine with VLEN >= 128
-mrvv-vect
atomic_compare_and_swapsi will use lr.w and sc.w to do the atomic operation on
RV64, however lr.w is doing sign extend to DI and compare instruction only have
DI mode on RV64, so the expected value should be sign extend before compare as
well, so that we can get right compare result.
gcc/ChangeLog
Take one more look, I think this option should work and integrate with
--param=riscv-autovec-preference= since they have similar jobs but
slightly different.
We have 3 value for --param=riscv-autovec-preference=: none, scalable
and fixed-vlmax
-mrvv-vector-bits=scalable is work like
--param=risc
to remove --param=riscv-autovec-preference and
> add -mrvv-vector-bits
>
> --
> juzhe.zh...@rivai.ai
>
>
> *From:* Kito Cheng
> *Date:* 2024-02-28 20:56
> *To:* pan2.li
> *CC:* gcc-patches ; juzhe.zhong
> ; yanzhang.wang ; rdapp.
07:02, Palmer Dabbelt wrote:
> >> On Wed, 28 Feb 2024 06:57:53 PST (-0800), jeffreya...@gmail.com wrote:
> >>>
> >>>
> >>> On 2/28/24 05:23, Kito Cheng wrote:
> >>>> atomic_compare_and_swapsi will use lr.w and sc.w to do the ato
think it's time to moving this forward.
Also we (SiFive) will send patches for clang/LLVM to relax that as well :)
https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/14
On Wed, Jan 10, 2024 at 2:31 AM Jeff Law wrote:
>
>
> On 1/8/24 06:47, Kito Cheng wrote:
> &g
LGTM!
On Wed, Jan 10, 2024 at 1:05 PM Juzhe-Zhong wrote:
>
> This patch is inspired by LLVM patches:
> https://github.com/llvm/llvm-project/pull/76550
> https://github.com/llvm/llvm-project/pull/77473
>
> Use vaaddu for AVG vectorization.
>
> Before this patch:
>
> vsetivlizero,8,
The idea makes sense to me, LGTM :)
On Thu, Jan 11, 2024 at 10:43 AM Juzhe-Zhong wrote:
>
> This patch fixes the known issues on SLP cases:
>
> ble a2,zero,.L11
> addiw t1,a2,-1
> li a5,15
> bleut1,a5,.L9
> srliw a7,t1,4
> sllia
Try to list all supported extensions: name, version and few description
for each extension.
gcc/ChangeLog:
* doc/invoke.texi (RISC-V Options): Add list of supported
extensions.
---
gcc/doc/invoke.texi | 463
1 file changed, 463 inserti
LGTM
On Thu, Jan 11, 2024 at 7:23 PM Jin Ma wrote:
>
> Due to the premature split optimizations for XTheadFMemIdx, GPR
> is allocated when reload allocates registers, resulting in the
> following insn.
>
> (insn 66 21 64 5 (set (reg:DF 14 a4 [orig:136 ] [136])
> (mem:DF (plus:SI (reg/f:S
LGTM
On Fri, Jan 12, 2024 at 7:37 AM Maciej W. Rozycki wrote:
>
> Verify that if-conversion succeeded through noce_try_store_flag_mask, as
> per PR rtl-optimization/105314, tightening the test case and making it
> explicit.
>
> gcc/testsuite/
> * gcc.target/riscv/pr105314.c: Scan
LGTM
On Fri, Jan 12, 2024 at 7:36 AM Maciej W. Rozycki wrote:
>
> The optimization levels pr105314.c is iterated over are needlessly
> overridden with "-O2", limiting the coverage of the test case to that
> level, perhaps with additional options the original optimization level
> has been supplied
Ok :)
Christoph Müllner 於 2024年1月15日 週一 23:17 寫道：
> On Mon, Jan 15, 2024 at 9:35 AM Liao Shihua wrote:
> >
> > Update v3 -> v4:
> > 1.Typo fix.
> > 2.Only test *intrinsic-32 on rv32 and *intrinsic-64 on rv64.
> > 3.Update Copyright year to 2024.
>
> Thanks, for fixing the rv32/rv64 issue
LGTM, the big endian for RISC-V has been there for a while, but we
don't pay enough attention to that, so I think reporting sorry for now
is a very reasonable way :)
On Tue, Jan 16, 2024 at 11:05 AM Juzhe-Zhong wrote:
>
> As PR113404 mentioned: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113404
OK, thanks :)
On Thu, Jan 18, 2024 at 4:17 PM Jakub Jelinek wrote:
>
> Hi!
>
> As I wrote recently, Bool is an undocumented unsupported keyword, as
> can be seen by
> grep Bool doc/options.texi *.awk
> The option parsing just parses and ignores all keywords it doesn't handle.
> But, because it is
LGTM
On Fri, Jan 12, 2024 at 3:32 PM juzhe.zh...@rivai.ai
wrote:
>
> This patch needs kito review. I can't approve that.
>
>
> juzhe.zh...@rivai.ai
>
>
> From: Jun Sha (Joshua)
> Date: 2024-01-12 11:20
> To: gcc-patches
> CC: jim.wilson.gcc; palmer; andrew; philip
LGTM, thanks :)
On Thu, Jan 18, 2024 at 5:59 PM Juzhe-Zhong wrote:
>
> While running various benchmarks, I notice we miss vi variant support for
> integer comparison.
> That is, we can vectorize code into vadd.vi but we can't vectorize into
> vmseq.vi.
>
> Consider this following case:
>
> void
Use "does not" rather than "cannot", because it's implementation issue.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_override_options_internal): Tweak
sorry message.
---
gcc/config/riscv/riscv.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/config/
Thanks, pushed to trunk :)
On Fri, Jan 19, 2024 at 10:30 AM KuanLin Chen wrote:
>
> UNSPEC_CLMUL is defined to define_c_enum in riscv.md, so
> it shouldn't be redefined to define_int_iterator again.
>
> gcc/ChangeLog:
>
> * config/riscv/vector-crypto.md (UNSPEC_CLMUL): Rename to UNSPEC_CLMUL_VC
Thanks, pushed to trunk :)
On Fri, Jan 19, 2024 at 10:36 AM juzhe.zh...@rivai.ai
wrote:
>
> OK
>
>
> juzhe.zh...@rivai.ai
>
>
> From: Kito Cheng
> Date: 2024-01-19 10:34
> To: rep.dot.nop; jeffreyalaw; rdapp.gcc; juzhe.zhong
Thanks! generally LGTM, but I would wait one more week to see any
other comments :)
On Fri, Jan 19, 2024 at 3:05 PM Monk Chiang wrote:
>
> Since the match.pd transforms (zero_one == 0) ? y : z y,
> into ((typeof(y))zero_one * z) y. Add splitters to recongize
> this expression to generate SFB in
Pushed to trunk :)
On Tue, Jan 16, 2024 at 10:33 PM Jeff Law wrote:
>
>
>
> On 1/9/24 17:58, Kito Cheng wrote:
> > Oops, I should leave more context here:
> >
> > Actually we discussed that years ago, and most people agree with that,
> > but I guess we are
>
> On Tue, 22 Nov 2022 13:50:28 PST (-0800), jeffreya...@gmail.com wrote:
> >
> > On 11/22/22 08:29, Palmer Dabbelt wrote:
> >> On Tue, 22 Nov 2022 07:20:15 PST (-0800), jeffreya...@gmail.com wrote:
> >>>
> >>> On 11/20/22 18:36, Kito Cheng wrote
LGTM, nice catch, I wasn't aware that would be a problem.
On Fri, Jan 19, 2024 at 4:12 PM Juzhe-Zhong wrote:
>
> This patch fixes memory hog found in SPEC2017 wrf benchmark which caused by
> RVV_VLMAX since RVV_VLMAX generate brand new rtx by gen_rtx_REG (Pmode,
> X0_REGNUM)
> every time we call
Oh, ok, I must have missed something during testing.
On Fri, Jan 19, 2024 at 5:37 PM juzhe.zh...@rivai.ai
wrote:
>
> Hi, kito.
>
> I found these following regression:
>
> FAIL: gcc.target/riscv/arch-27.c -O0 at line 7 (test for errors, line )
> FAIL: gcc.target/riscv/arch-27.c -O0 (test fo
Try to list all supported extensions: name, version and few description
for each extension.
v2 changes:
- Fix several typo.
- Add expantion info for vector crypto extensions.
- Drop zvl8192b, zvl16384b, zvl32768b and zvl65536b.
- Aadd zicntr and zihpm
gcc/ChangeLog:
* doc/invoke.texi
Hi Bernhard:
Thanks for such careful review! V2 send :)
On Tue, Jan 16, 2024 at 4:08 AM Bernhard Reutner-Fischer
wrote:
>
> Hi Kito!
>
> On Thu, 11 Jan 2024 17:06:09 +0800
> Kito Cheng wrote:
>
> > Try to list all supported extensions: name, version and few descriptio
Pushed to trunk, thanks :)
On Fri, Jan 19, 2024 at 5:41 PM juzhe.zh...@rivai.ai
wrote:
>
> LGTM.
>
>
> juzhe.zh...@rivai.ai
>
>
> From: Kito Cheng
> Date: 2024-01-19 17:40
> To: gcc-patches; kito.cheng; jim.wilson.gc
gcc/testsuite/ChangeLog:
* gcc.target/riscv/arch-27.c: Update scan message.
* gcc.target/riscv/arch-28.c: Ditto.
* gcc.target/riscv/attribute-10.c: Ditto.
* gcc.target/riscv/rvv/base/big_endian-2.c: Ditto.
* gcc.target/riscv/rvv/base/zvl-unimplemented-1.c: D
LGTM :)
On Mon, Jan 22, 2024 at 10:49 AM Juzhe-Zhong wrote:
>
> vfirst/vmsbf/vmsif/vmsof instructions are supposed to demand ratio instead of
> demanding sew_lmul.
> But my previous typo makes VSETVL PASS miss honor the risc-v v spec.
>
> Consider this following simple case:
>
> int foo4 (void *
LGTM, it's always good to improve some debug for vsetvli insertion
pass, it's really non-trivial optimization.
On Thu, Jan 25, 2024 at 4:59 PM Juzhe-Zhong wrote:
>
> While looking into PR113469, I notice the LCM delete a vsetvl incorrectly.
>
> This patch add dump information of all predecessors
Use this reduced testcase, but please verify this in your end again.
For the code change part, I would like to let other to review :P
struct a {
int b;
int c : 1;
int : 1;
} d();
typedef struct
{
int e;
struct {
int f;
};
} g;
int i;
char k, l, n;
void *m;
char *o;
void h();
char *j();
vo
It's stage 4, so I think it would be great to not disturb code base
too much, and adding intrinsic without adding VLS modes should be
better way to go, and here is not really something serious coding
style issue, just few minor indentation issue, so I gonna run
regression to make not break anythin
pushed :)
On Thu, Jan 25, 2024 at 9:53 PM Kito Cheng wrote:
>
> It's stage 4, so I think it would be great to not disturb code base
> too much, and adding intrinsic without adding VLS modes should be
> better way to go, and here is not really something serious coding
> s
LGTM
Jin Ma 於 2024年1月29日 週一 17:57 寫道：
> When using '%ld' to print 'long long int' variable, 'fprintf' will
> produce messy output on a 32-bit system, in an incorrect instruction
> being generated, such as 'th.lwib a1,(a0),-16,4294967295'. And the
> following error occurred during compilation:
>
> @@ -4868,6 +4968,63 @@ riscv_pass_fpr_pair (machine_mode mode, unsigned
> regno1,
>GEN_INT (offset2;
> }
>
> +static rtx
> +riscv_pass_vls_aggregate_in_gpr_or_fpr (struct riscv_arg_info *info,
> + machine_mode mode, u
Yeah, that should be put in unspec rather than unspecv, LGTM :)
On Tue, Jan 30, 2024 at 5:29 PM Christoph Müllner
wrote:
>
> The UNSPEC_XTHEAD* macros ended up in the unspecv enum,
> which broke gcc/testsuite/gcc.target/riscv/xtheadfmv-fmv.c.
> The INSNs expect these unspecs to be not volatile.
>
Thanks for fixing this bug! LGTM with one minor comment :)
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index 7b6111aa545..1de69019cd4 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -1382,6 +1382,38 @@ riscv_v_ext_mode_p (machine_mode mod
I realized there is 's' constraint which is defined in GCC generic
infra[1], and that's kinda what same as the new semantic of 'S' here,
(define_constraint "s"
"Matches a symbolic integer constant."
(and (match_test "CONSTANT_P (op)")
(match_test "!CONST_SCALAR_INT_P (op)")
(match_te
LGTM
On Wed, Dec 13, 2023 at 5:14 PM Feng Wang wrote:
>
> Patch v2: Change the implied ISA info using the minimum set and add
> dependencies info into the python script.
>
> Due to the crypto vector entension is depend on the Vector extension,
> so the "v" info is added into implied ISA info wit
LGTM
Juzhe-Zhong 於 2023年12月14日 週四 11:24 寫道：
> This patch fixes PR11153:
>
> ble a1,zero,.L8
> addiw a5,a1,-1
> li a4,4
> addisp,sp,-16
> mv a2,a0
> sext.w a3,a1
> bleua5,a4,.L9
> srliw a4,a3,2
> sl
ok
On Thu, Dec 14, 2023 at 8:08 PM Feng Wang wrote:
>
> This reverts commit ce7e66787b5b4ad385b21756da5a89171d233ddc.
> Will refactor this part in the same way as aarch64 sve.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-vector-builtins-functions.def (DEF_RVV_FUNCTION):
>
Why not just check the prefix is 'v'? I don't think xtheadvector able
to work with other vector stuffs like vector crypto or any other new
vector stuffs, then we don't need extra attribute.
On Thu, Dec 21, 2023 at 12:42 PM Jeff Law wrote:
>
>
>
> On 12/20/23 15:48, 钟居哲 wrote:
> > >> So rather th
`interrupt` function will backup fcsr register, but it fixed to SImode,
it's not big issue since fcsr only used 8 bits so far, however the
offset should still using UNITS_PER_WORD to prevent the stack offset
become non 8 byte aligned, it will cause problem for RV64.
gcc/ChangeLog:
* confi
LGTM :)
On Mon, Dec 25, 2023 at 5:18 PM Juzhe-Zhong wrote:
>
> Currently, we compute RVV V_REGS liveness during better_main_loop_than_p
> which is not appropriate
> time to do that since we for example, when have the codes will finally pick
> LMUL = 8 vectorization
> factor, we compute liveness
Thanks Feng, the patch is LGTM from my side, I am happy to accept
vector crypto stuffs for GCC 14, it's mostly intrinsic stuff, and the
only few non-intrinsic stuff also low risk enough (e.g. vrol, vctz)
On Fri, Dec 22, 2023 at 10:04 AM Feng Wang wrote:
>
> 2023-12-22 09:59 Feng Wang wrote:
>
>
Please move those code logic to thead.cc, e.g.
if (TARGET_XTHEADVECTOR)
return th_asm_output_opcode (asm_out_file, p);
And then implement th_asm_output_opcode in thead.cc.
On Wed, Jan 3, 2024 at 10:39 AM Jun Sha (Joshua)
wrote:
>
> There are some xtheadvector instructions that differ from RV
> diff --git a/gcc/config/riscv/riscv_th_vector.h
> b/gcc/config/riscv/riscv_th_vector.h
> new file mode 100644
> index 000..6f47e0c90a4
> --- /dev/null
> +++ b/gcc/config/riscv/riscv_th_vector.h
> @@ -0,0 +1,49 @@
> +/* RISC-V 'XTheadVector' Extension intrinsics include file.
> + Copyri
Hi Andrew:
That's kinda compromise and trade off on the t-head vector stuffs, we
would like to accept that, but without disturbing the vector 1.0
implementation too much, t-head vector is transitional product and it
will freeze/stop there forever without extending new stuffs like
vector bfloat and
LGTM with only few comment suggestion
Juzhe-Zhong 於 2024年1月3日 週三，18:50寫道：
> As PR113206 and PR113209, the bugs happens on the following situation:
>
> li a4,32
> ...
> vsetvli zero,a4,e8,m8,ta,ma
> ...
> slliw a4,a3,24
> sraiw a4,a4,24
>
Hi Fei:
> The fix is fine but maybe using s0 instead of t0 is better:
> 1. simpler codes.
> 2. less stack size
>
> current implementaion:
> >+**sd\tt0,40\(sp\)
> >+**frcsr\tt0
> >+**sw\tt0,32\(sp\) //save content of frcsr in stack
>
> use s0:
> >+**sd\tt0,40\(s
Committed to trunk, thanks!
Nice catch, LGTM :)
On Thu, Jan 4, 2024 at 4:28 PM Juzhe-Zhong wrote:
>
> Consider this following case:
>
> void
> f (int *restrict a, int *restrict b, int *restrict c, int *restrict d, int n)
> {
> for (int i = 0; i < n; i++)
> {
> int tmp = b[i] + 15;
> int tmp2 = tmp + b[i];
Thanks, verified and pushed to the trunk!
On Thu, Dec 28, 2023 at 10:12 AM KuanLin Chen wrote:
>
> According to spec, fmv.h checks if the input operands are correctly
> NaN-boxed. If not, the input value is treated as an n-bit canonical NaN.
> This patch fixs the issue that operands returned by
- Drop unnecessary including for stdlib.h and math.h
- Drop assert.h / assert, use __builtin_abort instead.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/binop/shift-scalar-template.h:
Use __builtin_abort instead of assert.
* gcc.target/riscv/rvv/autovec/cond/con
gcc/ChangeLog:
* config/riscv/riscv-v.cc (expand_load_store):
Remove `value`.
(expand_cond_len_op): Ditto.
(expand_gather_scatter): Ditto.
(expand_lanes_load_store): Ditto.
(expand_fold_extract_last): Ditto.
---
gcc/config/riscv/riscv-v.cc | 5 -
I am ok with merging this for GCC 14, as we discussed several times in
the RISC-V GCC sync up meeting, I think at least we reach consensus
among Jeff Law, Palmer Dabbelt and me.
But please be careful: don't break anything for standard vector stuff.
On Mon, Jan 8, 2024 at 10:11 AM joshua wrote:
>
te:
>
> Hi Kito,
>
> Thank you for your support.
> So even during stage 4, we can merge this for GCC 14?
>
>
>
>
>
> ------
> 发件人：Kito Cheng
> 发送时间：2024年1月8日(星期一) 11:06
> 收件人：joshua
> 抄 送："
docker/riscv-gnu-toolchain/gcc/gcc/testsuite/gcc.target/riscv/rvv/autovec/partial/single_rgroup-3.h:108:9:
> error: implicit declaration of function 'assert'
> [-Wimplicit-function-declaration]
>
> UNRESOLVED: gcc.target/riscv/rvv/autovec/partial/single_rgroup_run-3.c
> compilatio
Don't use assert, it not work well with multilib testing.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/partial/single_rgroup-3.h: Use
check + abort rather than assert.
---
.../riscv/rvv/autovec/partial/single_rgroup-3.h | 8 ++--
1 file changed, 6 inserti
Do you know how to build a ISA string with following extension?
- g
- c
- zba
- zbs
- svnapot
- zve64d
- zvl128b
Don't trial and error with your gcc and don't read RISC-V ISA spec! OK, I
believe it's impossible for most people, even I work for RISC-V so many years,
I remember most of the rule
-march was require canonical order before, however it's not easy for
most user when we have so many extension, so this patch is relax the
constraint, -march accept the ISA string in any order, it only has few
requirement:
1. Must start with rv[32|64][e|i|g].
2. Multi-letter and single letter exten
Minor refactor, preparation for further change.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_subset_list::parse_base_ext): New.
(riscv_subset_list::parse): Extract part of logic into
riscv_subset_list::parse_base_ext.
* config/riscv/riscv-sub
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_subset_list::parse_std_ext): Remove.
(riscv_subset_list::parse_multiletter_ext): Remove.
* config/riscv/riscv-subset.h
(riscv_subset_list::parse_std_ext): Remove.
(riscv_subset_list::parse_m
We has relaxed -march string, it no longer require canonical order, so
we need update some of those testcase.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/arch-23.c: Update test.
* gcc.target/riscv/arch-27.c: Ditto.
* gcc.target/riscv/arch-28.c: Ditto.
* gcc.target/
---
gcc/doc/invoke.texi | 16
1 file changed, 16 insertions(+)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 68d1f364ac0..81ee7ac758a 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -30037,6 +30037,22 @@ Generate code for given RISC-V ISA (e.g.@:
@sa
LGTM
On Sun, Dec 3, 2023 at 5:16 AM Christoph Müllner <
christoph.muell...@vrull.eu> wrote:
> This patch documents the optimization parameter
> riscv-strcmp-inline-limit, which can be used to tweak the behaviour
> of -minline-strcmp and -minline-strncmp.
>
> gcc/ChangeLog:
>
> PR target/1
Wait, I got this on my machine?
../../../../riscv-gnu-toolchain-trunk/gcc/gcc/doc/invoke.texi:29774: misplaced }
../../../../riscv-gnu-toolchain-trunk/gcc/gcc/doc/invoke.texi:29786: misplaced }
On Mon, Dec 4, 2023 at 10:43 AM Kito Cheng wrote:
>
> LGTM
>
> On Sun, Dec 3, 202
Extract the logic of checking conflict extensions to a standard alone
function, prepare to add more checking logic.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_subset_list::check_conflict_ext): New.
(riscv_subset_list::parse): Move checking conflict ext. to
RISC-V ISA implication rules become little bit complicated than before,
it may come with condition, so this commit extend the capability of
riscv_implied_info_t, also make it more...C++ize.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_implied_predicator_t): New.
(ri
x280 is one of SiFive core, and it release for a while, also
upstream LLVM already support that.
[1] https://www.sifive.com/cores/intelligence-x280
gcc/ChangeLog:
* config/riscv/riscv-cores.def: Add sifive-x280.
* doc/invoke.texi (RISC-V Options): Add sifive-x280
gcc/testsuite/C
LGTM again :)
On Mon, Dec 4, 2023 at 2:44 PM Feng Wang wrote:
>
> Rebase and resend this patch due to it was not added into patchwork
> before. Kito had already reviewed it. Please refer to
> https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg327499.html
>
> This patch add the Zvkb subset of
RISC-V newlib patch send, one for libgloss and another one for libm,
the libm issue is because we don't have right long double support,
however newlib has supported that few months ago, and porting effort
is minor, so I just port that to fix the issue :)
https://sourceware.org/pipermail/newlib/202
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_subset_list::check_conflict_ext): Check zcd conflicts
with zcmt and zcmp.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/arch-29.c: New test.
* gcc.target/riscv/arch-30.c: New test.
---
gcc/common/c
Hi Feng:
Thanks for the patch! a few inline comments below, also don't include
all test files from doc generator, only include a few within the patch
is fine, e.g. pick one for each group, so that it won't make GCC
source tree bloat too much.
> diff --git a/gcc/config/riscv/riscv.md b/gcc/config/
LGTM
On Mon, Dec 4, 2023 at 5:55 PM Christoph Müllner
wrote:
>
> This patch documents the optimization parameter
> riscv-strcmp-inline-limit, which can be used to tweak the behaviour
> of -minline-strcmp and -minline-strncmp.
>
> gcc/ChangeLog:
>
> PR target/112650
> * doc/invoke.
both patches are landed, newlib trunk should be able to build with gcc
trunk now.
On Mon, Dec 4, 2023 at 3:45 PM Kito Cheng wrote:
>
> RISC-V newlib patch send, one for libgloss and another one for libm,
> the libm issue is because we don't have right long double support,
> h
committed to trunk, thanks :)
On Mon, Dec 4, 2023 at 5:21 PM Christoph Müllner
wrote:
>
> On Mon, Dec 4, 2023 at 8:48 AM Kito Cheng wrote:
>
> LGTM
>
> I've double-checked this in the Zc-1.0.4-3.pdf:
> * Zcmp is incompatible with Zcd
> * Zcmp depends on Zca
>
LGTM
On Tue, Nov 28, 2023 at 9:17 PM Mary Bennett wrote:
>
> Spec:
> github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md
>
> Contributors:
> Mary Bennett
> Nandni Jamnadas
> Pietra Ferreira
> Charlie Keaney
> Jessica Mills
> Craig Blackmore
> Simon
LGTM
On Tue, Nov 28, 2023 at 9:17 PM Mary Bennett wrote:
>
> gcc/ChangeLog:
> * config/riscv/constraints.md: CVP2 -> CV_alu_pow2.
> * config/riscv/corev.md: Likewise.
> ---
> gcc/config/riscv/constraints.md | 15 ---
> gcc/config/riscv/corev.md | 4 ++--
> 2 fi
On Tue, Nov 28, 2023 at 9:17 PM Mary Bennett wrote:
>
> Spec:
> github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md
>
> Contributors:
> Mary Bennett
> Nandni Jamnadas
> Pietra Ferreira
> Charlie Keaney
> Jessica Mills
> Craig Blackmore
> Simon Cook
> index 7d7b952d817..e7d4ad1760c 100644
> --- a/gcc/config/riscv/corev.md
> +++ b/gcc/config/riscv/corev.md
> @@ -27,6 +27,25 @@
>
>;;CORE-V EVENT LOAD
>UNSPECV_CV_ELW
> +
> + ;;CORE-V BITMANIP
> + UNSPEC_CV_BITMANIP_EXTRACT
> + UNSPEC_CV_BITMANIP_EXTRACT_INSN
> + UNSPEC_CV_BITMANIP_EXT
There are few formatting issues, but I think this is generally OK for
intrinsic support only, but one question before I formally say LGTM
for this patch: are you interested in making it able to code gen with
GNU vector and also for auto vectorization stuff? If so, I can spend
more time on reviewing
You could add [NFC] to the title for this kind of patch to declare its
clean up or refactor patch without change any function or feature,
that would be easier for reviewer, anyway LGTM as well
On Wed, Dec 6, 2023 at 12:50 PM Li Xu wrote:
>
> From: xuli
>
> gcc/ChangeLog:
>
> * config/ris
LGTM
On Tue, Dec 5, 2023 at 11:16 PM Christoph Müllner
wrote:
>
> The XTheadMemIdx support relies on the fact that memory operands that
> can be expressed by XTheadMemIdx instructions, will only appear as
> operands of such instructions. For internal instruction generation
> this is guaranteed b
> #ifndef DEF_RVV_FUNCTION
> -#define DEF_RVV_FUNCTION(NAME, SHAPE, PREDS, OPS_INFO)
> +#define DEF_RVV_FUNCTION(NAME, SHAPE, PREDS, OPS_INFO, AVAIL)
#define DEF_RVV_FUNCTION(NAME, SHAPE, PREDS, OPS_INFO, ...)
And add a comment to mention 5th argument is optional for AVAIL.
> #endif
>
> /* In
> @@ -31,624 +31,627 @@ along with GCC; see the file COPYING3. If not see
> - OPS_INFO describes all information of return type and each
> argument type.
>
> + - AVAIL this argument is the optional for AVAIL.Determin the enable
> + of the intrinsic function.
> +
> */
> #if
> Without comma, there is a warning "warning: ISO C++11 requires at least one
> argument for the "..." in a variadic macro".
> So I add the comma.
Oh, thanks, I wasn't aware that, maybe take one more argument to '...'
#define DEF_RVV_FUNCTION(NAME, SHAPE, PREDS, ...)
Anyway my intention is to r
I am happy with this change now, however I didn't see any place call avail
function yet? Do I miss something? Are you planning to send follow up
patches to add that?
If so, LGTM.
LGTM
On Mon, Dec 11, 2023 at 1:19 PM Juzhe-Zhong wrote:
>
> This patch fixes multiple ICEs in full coverage testing:
>
> cc1: internal compiler error: in riscv_legitimize_poly_move, at
> config/riscv/riscv.cc:2456^M
> 0x1fd8d78 riscv_legitimize_poly_move^M
> ../../../../gcc/gcc/config/ri
> diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr83518.C
> b/gcc/testsuite/g++.dg/tree-ssa/pr83518.C
> index b8a2bd1ebbd..6f2fc56c82c 100644
> --- a/gcc/testsuite/g++.dg/tree-ssa/pr83518.C
> +++ b/gcc/testsuite/g++.dg/tree-ssa/pr83518.C
> @@ -24,4 +24,4 @@ unsigned test()
>return sum;
> }
>
> -
On Mon, Dec 11, 2023 at 5:48 PM Sergei Lewis wrote:
>
> gcc/ChangeLog
>
> * config/riscv/riscv-protos.h (riscv_vector::expand_vec_setmem): New
> function
> declaration.
>
> * config/riscv/riscv-string.cc (riscv_vector::expand_vec_setmem): New
> function: this generates an inline v
LGTM
On Mon, Dec 19, 2022 at 9:08 AM Christoph Muellner
wrote:
>
> From: Christoph Müllner
>
> This adds T-Head's XuanTie C906 to the list of known cores as "thead-c906".
> The C906 is shipped for quite some time (it is the core of the Allwinner D1).
> Note, that the tuning struct for the C906 i
201 - 300 of 1788 matches
Mail list logo
