This patch set adding basic -march option support and feature test marco for
vector extensions, and also extend the syntax of arch string for vector
extensions, although that should change RISC-V ISA manual first would be
better, but we don't got response[1] yet, and that will block whole vector
ex
RISC-V spec only allow alphabetical name for extension before, however
vector extension add several extension named with digits, so we try to
extend the naming rule.
Ref:
https://github.com/riscv/riscv-isa-manual/pull/718
gcc/ChangeLog:
* common/config/riscv/riscv-common.c
(riscv
gcc/ChangeLog:
* common/config/riscv/riscv-common.c (riscv_implied_info): Add
vector extensions.
(riscv_ext_version_table): Add version info for vector extensions.
(riscv_ext_flag_table): Add option mask for vector extensions.
* config/riscv/riscv-opts.h (MA
`h` was the prefix of multi-letter extension name, but it become a
extension in later RISC-V isa spec.
Fortunately we don't have any extension really defined is prefixed
with `h`, so we can just change that.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_ext_version_table):
LGTM, thanks!
On Wed, Nov 2, 2022 at 7:59 AM Christoph Muellner
wrote:
>
> From: Christoph Müllner
>
> This patch documents the new RISC-V Zawrs support.
>
> Signed-off-by: Christoph Müllner
> ---
> htdocs/gcc-13/changes.html | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff
poly_int64 is non-trivial type, we need to clean up manully instead
of memset to prevent this warning.
../../gcc/gcc/config/riscv/riscv.cc: In function 'void
riscv_compute_frame_info()':
../../gcc/gcc/config/riscv/riscv.cc:4113:10: error: 'void* memset(void*, int,
size_t)' clearing an object of
../../gcc/common/config/riscv/riscv-common.cc: In function 'const char*
riscv_multi_lib_check(int, const char**)':
../../gcc/common/config/riscv/riscv-common.cc:1451:11: error: bare apostrophe
''' in format [-Werror=format-diag]
1451 | "Can't find suitable multilib set for %<-march=%s%>/%<
> > and so it doesn't make
> > sense to mandate any particular ordering.
>
> No. It affects Z* extension ordering...
+1, we really need the order in ISA spec so that we could know the
canonical order for z* exts.
Hi Tsukasa:
LGTM, and did you mind adding Signed-off-by to your patch and resending again?
I think this patch is small enough and the copyright process should
not be a blocker for this patch :)
See also: https://gcc.gnu.org/dco.html
On Sun, Apr 24, 2022 at 1:25 PM Tsukasa OI wrote:
>
> **note*
---
htdocs/gcc-12/changes.html | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index 78b7b05f..e9f132c0 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -736,7 +736,18 @@ function M
gcc/ChangeLog:
* common/config/riscv/riscv-common.c
(riscv_subset_list::parse_multiletter_ext): Checking multiletter
extension has more than 1 letter.
gcc/testsuite/ChangeLog
* gcc.target/riscv/arch-7.c: New.
* gcc.target/riscv/attribute-10.c: Update test
Committed, thanks :)
On Fri, Nov 6, 2020 at 6:21 AM Jeff Law wrote:
>
> On 10/16/20 3:01 AM, Martin Liška wrote:
> > On 10/16/20 9:41 AM, Kito Cheng wrote:
> >> I think it is still useful for other targets which are not supporting
> >> libsanitizer yet, so in t
gcc/ChangeLog:
* common/config/riscv/riscv-common.c (riscv_implied_info):
Add static and const.
(riscv_subset_list::handle_implied_ext): Add const due to
riscv_implied_info changed to const.
---
gcc/common/config/riscv/riscv-common.c | 4 ++--
1 file changed, 2 ins
- CSR related instructions and fence instructions has to be splitted from
baseline ISA, zicsr and zifencei are corresponding sub-extension.
gcc/ChangeLog:
* common/config/riscv/riscv-common.c (riscv_implied_info):
d and f implied zicsr.
(riscv_ext_flag_table): Handle z
- ISA spec has specify the order between multi-letter extensions, implied
extension also need to follow store in canonical ordering, so
most easy way is we keep that in-order during insertion.
gcc/ChangeLog:
* common/config/riscv/riscv-common.c (single_letter_subset_rank): New.
Current GCC implementation is RISC-V ISA 2.2, this patch set implement
v20190608 and v20191213, and also add option -misa-spec=[2.2|20190608|20191213]
to change the default ISA spec version.
There is one major incompatible
That option will effect the default version of each sub-extension, for e
Current GCC implementation is RISC-V ISA 2.2, this patch set implement
v20190608 and v20191213, and also add option -misa-spec=[2.2|20190608|20191213]
to change the default ISA spec version.
There is one major incompatible
That option will effect the default version of each sub-extension, for e
- New option -misa-spec support: -misa-spec=[2.2|20190608|20191213] and
corresponding configuration option --with-isa-spec.
- Current default ISA spec set to 2.2, but we intend to bump this to
20191213 or later in next release.
gcc/ChangeLog:
* common/config/riscv/riscv-common.c
- New option -misa-spec support: -misa-spec=[2.2|20190608|20191213] and
corresponding configuration option --with-isa-spec.
- Current default ISA spec set to 2.2, but we intend to bump this to
20191213 or later in next release.
gcc/ChangeLog:
* common/config/riscv/riscv-common.c
- CSR related instructions and fence instructions has to be splitted from
baseline ISA, zicsr and zifencei are corresponding sub-extension.
gcc/ChangeLog:
* common/config/riscv/riscv-common.c (riscv_implied_info):
d and f implied zicsr.
(riscv_ext_flag_table): Handle z
- ISA spec has specify the order between multi-letter extensions, implied
extension also need to follow store in canonical ordering, so
most easy way is we keep that in-order during insertion.
gcc/ChangeLog:
* common/config/riscv/riscv-common.c (single_letter_subset_rank): New.
gcc/ChangeLog
PR target/93304
* config/riscv/riscv-protos.h (riscv_hard_regno_rename_ok): New.
* config/riscv/riscv.c (riscv_hard_regno_rename_ok): New.
* config/riscv/riscv.h (HARD_REGNO_RENAME_OK): Defined.
gcc/testsuite/ChangeLog
PR target/93304
Hi Jim:
Thanks, fixed and committed, and it's OK to commit to gcc 8/9 next week?
On Tue, Jan 21, 2020 at 7:13 AM Jim Wilson wrote:
> On Mon, Jan 20, 2020 at 12:04 AM Kito Cheng wrote:
> > gcc/ChangeLog
> >
> > PR target/93304
> >
Tested and committed to gcc 9 branch.
On Wed, Jan 22, 2020 at 2:35 AM Jim Wilson wrote:
> On Mon, Jan 20, 2020 at 6:44 PM Kito Cheng wrote:
> > Thanks, fixed and committed, and it's OK to commit to gcc 8/9 next week?
>
> Yes, that is OK with me.
>
> Jim
>
- strlenopt-81.c has same limitation as strlenopt-80.c, this
optimization only work when memcpy expand into load/store.
ChangeLog
gcc/testsuite
Kito Cheng
* gcc.dg/strlenopt-81.c: Add target limitation.
---
gcc/testsuite/gcc.dg/strlenopt-81.c | 6 +-
1 file changed, 5
ead of using ELIM marco.
2. Only allow part of target run this testcase like strlenopt-80.c.
This patch take the second way.
Thanks :)
On Sat, Feb 15, 2020 at 1:22 AM Martin Sebor wrote:
>
> On 2/13/20 8:34 PM, Kito Cheng wrote:
> > - strlenopt-81.c has same limitation as strlen
list too long" error when we tried to add more
multi-lib reuse rule.
* Here is an example for RISC-V multi-lib rules:
https://gist.github.com/kito-cheng/0289cd42d9a756382e5afeb77b42b73b
V3 Changes:
- Doc fix for the first patch.
- Fix lots of typo.
- Rewrite multi-lib option
-lib reuse rule.
So I think it would be great to have a target specific way to determine
the multi-lib re-use rule, then we could write those rule in C, instead
of expand every possible case in MULTILIB_REUSE.
* Here is an example for RISC-V multi-lib rules:
https://gist.github.com/
Use TARGET_COMPUTE_MULTILIB to search the multi-lib reuse for riscv*-*-elf*,
according following rules:
1. Check ABI is same.
2. Check both has atomic extension or both don't have atomic extension.
- Because mix soft and hard atomic operation doesn't make sense and
won't work as expect
Bit manipulation extension[1] is finishing the public review and waiting for
the rest of the ratification process, I believe that will become a ratified
extension soon, so I think it's time to submit to upstream for review now :)
As the title included RFC, it's not a rush to merge to trunk yet, I
2021-09-23 Kito Cheng
gcc/ChangeLog:
* common/config/riscv/riscv-common.c (riscv_ext_version_table):
Add zba, zbb, zbc and zbs.
(riscv_ext_flag_table): Ditto.
* config/riscv/riscv-opts.h (MASK_ZBA): New.
(MASK_ZBB): Ditto.
(MASK_ZBC): Ditto
From: Jim Wilson
2021-09-23 Jim Wilson
Kito Cheng
Jia-Wei Chen
gcc/ChangeLog:
* config/riscv/bitmanip.md (*zero_extendsidi2_bitmanip): New.
(*shNadd): Ditto.
(*shNadduw): Ditto.
(*add.uw): Ditto.
(*slliuw): Ditto
2021-09-23 Kito Cheng
gcc/ChangeLog:
* config/riscv/riscv.c (riscv_extend_cost): Handle cost model
for zba extension.
(riscv_rtx_costs): Ditto.
---
gcc/config/riscv/riscv.c | 81
1 file changed, 81 insertions(+)
diff --git a/gcc
From: Jim Wilson
2021-09-23 Jim Wilson
Kito Cheng
Jia-Wei Chen
gcc/ChangeLog:
* config/riscv/bitmanip.md (bitmanip_bitwise): New.
(bitmanip_minmax): New.
(clz_ctz_pcnt): New.
(bitmanip_optab): New.
(bitmanip_insn): New
2021-09-23 Kito Cheng
gcc/ChangeLog:
* config/riscv/riscv.c (riscv_extend_cost): Handle cost model
for zbb extension.
(riscv_rtx_costs): Ditto.
---
gcc/config/riscv/riscv.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/gcc/config/riscv/riscv.c b
From: Jim Wilson
gcc/ChangeLog:
* config/riscv/riscv.c (riscv_build_integer_1): Build integer
with rotate.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/zbb-li-rotr.c: New.
---
gcc/config/riscv/riscv.c | 41
gcc/testsuite/gcc.targ
From: Jim Wilson
2021-09-23 Jim Wilson
Kito Cheng
gcc/ChangeLog:
* config/riscv/bitmanip.md (shiftm1): New.
(*bset): Ditto.
(*bset_mask): Ditto.
(*bset_1): Ditto.
(*bset_1_mask): Ditto.
(*bseti): Ditto.
(*bclr): Ditto
2021-09-23 Kito Cheng
gcc/ChangeLog:
* config/riscv/riscv.c (riscv_rtx_costs): Handle cost model
for zbs extension.
---
gcc/config/riscv/riscv.c | 47
1 file changed, 47 insertions(+)
diff --git a/gcc/config/riscv/riscv.c b/gcc/config
> diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
> index 225e5b259c1..1a786f31258 100644
> --- a/gcc/config/riscv/riscv.md
> +++ b/gcc/config/riscv/riscv.md
> @@ -1812,7 +1812,7 @@ (define_expand "clear_cache"
>
> (define_insn "fence"
>[(unspec_volatile [(const_int 0)] UNSP
IIRC this issue should be resolved?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99314
On Sun, Oct 31, 2021 at 5:34 PM wrote:
>
> From: linsinan1995 <47880367+linsinan1...@users.noreply.github.com>
>
> ---
> gcc/config/riscv/riscv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> di
Hi Si-Yu:
Thanks for your patch!
Here is a general comment for this patch-set, GCC require ChagneLog in
commit log, and seems like that is included in your commit log, you
can refer other commit log to see how changelog wrote.
Scalar cryptography extension seems not define builtin and intrinsic
We was assume the Z* extension should be more than 2 char, so we put an
assertion there, but it should just an error or warning rather than an
assertion, however RISC-V has add `Zk` extension, which just 2 char, so
actually, we should just allow that.
gcc/ChangeLog
PR target/102957
This issue cause zifencei never correctly appended on the ISA string.
gcc/ChangeLog
* common/config/riscv/riscv-common.c (riscv_subset_list::to_string): Fix
wrong marco checking.
---
gcc/common/config/riscv/riscv-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
dif
gcc/testsuite/ChangeLog:
* g++.dg/modules/omp-1_a.C: Check pthread is available.
* g++.dg/modules/omp-1_b.C: Ditto.
* g++.dg/modules/omp-1_c.C: Ditto.
* g++.dg/modules/omp-2_a.C: Ditto.
* g++.dg/modules/omp-2_b.C: Ditto.
---
gcc/testsuite/g++.dg/modules/omp
gcc/ChangeLog:
* config/riscv/riscv.h (ASM_SPEC): Pass -mno-relax.
---
gcc/config/riscv/riscv.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
index f3e85723c85..f47d5b40a66 100644
--- a/gcc/config/riscv/riscv.h
+++ b/gcc/config/risc
__builtin___clear_cache was able to accept constant address for the
argument, but it seems no longer accept recently, and it even not
accept constant address which is hold in variable when optimization is
enable:
```
void foo3(){
void *yy = (void*)0x1000;
__builtin___clear_cache(yy, yy);
}
```
__builtin___clear_cache was able to accept constant address for the
argument, but it seems no longer accept recently, and it even not
accept constant address which is hold in variable when optimization is
enable:
```
void foo3(){
void *yy = (void*)0x1000;
__builtin___clear_cache(yy, yy);
}
```
Hi Andrew:
> The error message would have been emitted from
> expand_builtin___clear_cache and maybe_emit_call_builtin___clear_cache
> would not have been called from user code.
> All other uses of maybe_emit_call_builtin___clear_cache are internal
> to gcc and should have the correct mode so ass
__builtin___clear_cache was able to accept constant address for the
argument, but it seems no longer accept recently, and it even not
accept constant address which is hold in variable when optimization is
enable:
```
void foo3(){
void *yy = (void*)0x1000;
__builtin___clear_cache(yy, yy);
}
```
Oct 8, 2021 at 2:47 PM Richard Biener
wrote:
>
> On Fri, Oct 8, 2021 at 4:40 AM Kito Cheng wrote:
> >
> > __builtin___clear_cache was able to accept constant address for the
> > argument, but it seems no longer accept recently, and it even not
> > accept constant add
Hi Christoph:
> I think this needs another specification class (there is a
> specification for the instructions and it is in public review).
> Proposal: ISA_SPEC_CLASS_FROZEN_2021
That's a good point, but ISA_SPEC_CLASS_FROZEN_2021 is hard to
reference to which spec, so I would prefer to add a -m
> > That's a good point, but ISA_SPEC_CLASS_FROZEN_2021 is hard to
> > reference to which spec, so I would prefer to add a -misa-spec=2021 to
> > align platform/profile spec, and then ISA_SPEC_CLASS_2021, and before
> > RISC-V platform/profile spec has released, let keep
> > ISA_SPEC_CLASS_NONE :p
Hi Shi-Hua:
> --- a/gcc/config/riscv/riscv.c
> +++ b/gcc/config/riscv/riscv.c
> @@ -1872,7 +1872,7 @@ riscv_rtx_costs (rtx x, machine_mode mode, int
> outer_code, int opno ATTRIBUTE_UN
> case MULT:
>if (float_mode_p)
> *total = tune_param->fp_mul[mode == DFmode];
> - els
Canonical order for z-prefixed extension are rely on the canonical order of
single letter extension, however we didn't put i into the list before,
so when we put zicsr or zifencei it will got exception.
gcc/ChangeLog:
* config/riscv/arch-canonicalize (CANONICAL_ORDER): Add `i` to
We're wrongly guard zero_extendsidi2_internal pattern both ZBA and ZBB,
only ZBA provide zero_extendsidi2 instruction.
gcc/ChangeLog
* config/riscv/riscv.md (zero_extendsidi2_internal): Allow ZBB
use this pattern.
---
gcc/config/riscv/riscv.md | 2 +-
1 file changed, 1 insertion(
It was undocument before, but it might used in linux kernel for resolve
code model issue, so LLVM community suggest we should document that,
so that make it become supported/documented/non-internal machine constraints.
gcc/ChangeLog:
PR target/101275
* config/riscv/constraints.md
gcc/
* config.gcc (riscv*-*-*): Detect which python is available.
---
gcc/config.gcc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 93e2b3219b9..3df9b52cf25 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -4730,9 +4730,10 @@
--with-multilib-generator was only support for different ISA/ABI
combination, however code model is effect the code gen a lots it
should able to handled in multilib mechanism.
Adding `--cmodel=` option to `--with-multilib-generator` to generating
multilib combination with different code model.
E.
list too long" error when we tried to add more
multi-lib reuse rule.
* Here is an example for RISC-V multi-lib rules:
https://gist.github.com/kito-cheng/0289cd42d9a756382e5afeb77b42b73b
V2 Changes:
- NO changes for first patch(TARGET_COMPUTE_MULTILIB part) since first version.
- Handle op
-lib reuse rule.
So I think it would be great to have a target specific way to determine
the multi-lib re-use rule, then we could write those rule in C, instead
of expand every possible case in MULTILIB_REUSE.
* Here is an example for RISC-V multi-lib rules:
https://gist.github.com/
Use TARGET_COMPUTE_MULTILIB to search the multi-lib reuse for riscv*-*-elf*,
according following rules:
1. Check ABI is same.
2. Check both has atomic extension or both don't have atomic extension.
- Because mix soft and hard atomic operation doesn't make sense and
won't work as expect
This patch is a good and simple improvement which could be an independent patch.
There is only 1 comment from me for this patch, could you also add @
to cbranch pattern for floating mode, I would prefer make the
gen_cbranch4 could handle floating mode for consistency.
So feel free to commit this
Thanks for your patch! this is generally in good shape, just a few
minor comments :)
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index 2135dfde9c8..afe486ba47b 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -6314,6 +6314,18 @@ Permissible values for this parame
LGTM, thanks :)
On Fri, Mar 1, 2024 at 5:10 PM Li Xu wrote:
>
> From: xuli
>
> Standard vector calling convention variant will only enabled when function
> has vector argument or returning value by default, however user may also
> want to invoke function without that during a vectorized loop at
LGTM :)
On Tue, Mar 12, 2024 at 3:07 PM wrote:
>
> From: Pan Li
>
> Notice some code style issue(s) when add __riscv_v_fixed_vlen, includes:
>
> * Meanless empty line.
> * Line greater than 80 chars.
> * Indent with 3 space(s).
> * Argument unalignment.
>
> gcc/ChangeLog:
>
> * config/ri
LGTM, thanks :)
On Wed, Mar 20, 2024 at 2:07 PM wrote:
>
> From: Pan Li
>
> This patch depends on below ICE fix.
>
> https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647915.html
>
> The function target attribute should be on a per-function basis.
> For example, we have 3 function as below:
>
LGTM too :)
On Mon, Mar 18, 2024 at 11:35 PM Robin Dapp wrote:
>
> LGTM as well.
>
> Regards
> Robin
>
> +
> + /* Make sure the implied or combined extension is included after add
> + a new std extension to subset list. For exmaple as below,
> +
> + void __attribute__((target("arch=+v"))) func () with -march=rv64gc.
> +
> + The implied zvl128b and zve64d of the std v should be included
> For the vint*m*_t below operations are allowed.
> * The sizeof.
> * The global variable(s).
> * The element of union and struct.
> * The cast to other equalities.
> * CMP: >, <, ==, !=, <=, >=
The result of comparison should be vbool* rather than v[u]int*.
> * ALU: +, -, *, /, %, &, |, ^, >>, <
p to correct me the behavior of the riscv_rvv_vector_bits
> attribute?
> Sort of details and I suspect there is something missing, or different
> behavior compared with clang side.
>
> Pan
>
> -Original Message-
> From: Stefan O'Rear
> Sent: Tuesday, March 12, 202
> > &, ^, | has supported on clang, so I think we should support that as well
>
> Looks gcc lack of such operation right now, so mark the TYPE_INDIVISIBLE_P
> (type) = 0 as aarch64 did.
> I have a try but I am afraid we need separated patch to take care of it for
> risk control consideration.
Ye
LGTM, thanks :)
On Fri, Mar 22, 2024 at 9:13 AM wrote:
>
> From: Pan Li
>
> This patch would like to fix one ICE for __attribute__((target("arch=+v"))
> and likewise extension(s). Given we have sample code as below:
>
> void __attribute__((target("arch=+v")))
> test_2 (int *a, int *b, int *out,
LGTM, thanks :)
On Fri, Mar 22, 2024 at 2:55 PM wrote:
>
> From: Pan Li
>
> This patch would like to introduce one new gcc attribute for RVV.
> This attribute is used to define fixed-length variants of one
> existing sizeless RVV types.
>
> This attribute is valid if and only if the mrvv-vector-
LGTM, thanks :)
On Mon, Mar 25, 2024 at 3:42 PM wrote:
>
> From: Pan Li
>
> This patch would like to allow the RVV intrinsic when function is
> attributed as target("arch=+v") and build with rv64gc. For example:
>
> vint32m1_t
> __attribute__((target("arch=+v")))
> test_1 (vint32m1_t a, vint32m
LGTM, and committed to trunk :)
On Thu, Mar 28, 2024 at 5:37 AM Palmer Dabbelt wrote:
>
> We aren't doing anything with vxsat right now, but I'd like to add it as
> an accepted register to the clobber list. If we get this into GCC-14
> then we'll avoid some preprocessor-based twiddling if we eve
Just tried something interesting:
$ riscv64-unknown-linux-gnu-gcc -march=rv64gc -O
target_attribute_v_with_intrinsic-9.c -S # Work
$ riscv64-unknown-linux-gnu-gcc -march=rv64gc_zve32x -O
target_attribute_v_with_intrinsic-9.c -S # Not work
Also I guess all zvk* and zvbb may also need to be added a
: Add with_tls configuration option, and a few readability improvements.
> Added Changelog.
> v3: Add documentation per Kito's suggestion.
> Fix minor issues pointed out by Kito and Jeff.
> Thanks Kito Cheng and Jeff Law for review.
> v4: Add TLSDESC GD assembly test.
>
LGTM
On Sat, Mar 30, 2024 at 9:35 PM wrote:
>
> From: Pan Li
>
> This patch would like to fix one unused variable as below:
>
> ../../gcc/common/config/riscv/riscv-common.cc: In static member function
> 'static riscv_subset_list* riscv_subset_list::parse(const char*, location_t)':
> ../../gcc/co
lgtm
On Sat, Mar 30, 2024 at 8:07 PM wrote:
>
> From: Pan Li
>
> This patch would like to fix below misspelled term in error message.
>
> ../../gcc/config/riscv/riscv-vector-builtins.cc:4592:16: error:
> misspelled term 'builtin function' in format; use 'built-in function' instead
> [-Werror=fo
Committed to trunk, thanks Tatsuyuki!
On Fri, Mar 29, 2024 at 2:32 PM Kito Cheng wrote:
>
> Hi Tatsuyuki:
>
> Thanks for your hard work and keep updating, the patch set is LGTM, I
> plan to commit this next week if no further comments :)
>
> Hi MaskRay:
>
> Thanks for
---
htdocs/gcc-14/changes.html | 155 -
1 file changed, 154 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 2d8968cf..6cbb2e8f 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -7
I was thinking we may guarded with TARGET_VECTOR and TARGET_HARD_FLOAT
or checking with ABI in riscv_function_value_regno_p, however I think
it's fine with current implementation (no checking) after checking all
use site of `targetm.calls.function_value_regno_p`, so LGTM :)
Thanks Pan for fixing t
Committed with fixes, thanks :)
On Thu, Apr 11, 2024 at 12:18 AM Palmer Dabbelt wrote:
> On Wed, 10 Apr 2024 00:58:00 PDT (-0700), kito.ch...@sifive.com wrote:
> > ---
> > htdocs/gcc-14/changes.html | 155 -
> > 1 file changed, 154 insertions(+), 1 deletion(-
Could you add some document for doc/invoke.texi, I just added a list
for listing all supported extensions before[1].
[1]
https://github.com/gcc-mirror/gcc/commit/19260a04ba6f75b1fae52afab50dcb43d44eb259
On Thu, Feb 1, 2024 at 4:29 PM Monk Chiang wrote:
>
> The RISC-V Profiles specification here
Pushed to trunk, thanks :)
On Thu, Feb 1, 2024 at 5:16 PM Monk Chiang wrote:
>
> The RISC-V Profiles specification here:
> https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#7-new-isa-extensions
>
> These extensions don't add any new features but
> describe existing features. So this
LGTM
On Thu, Feb 1, 2024 at 8:25 PM Juzhe-Zhong wrote:
>
> I realize there is a RTL regression between GCC-14 and GCC-13.
> https://godbolt.org/z/Ga7K6MqaT
>
> GCC-14:
> (insn 9 13 31 2 (set (reg:DI 15 a5 [138])
> (unspec:DI [
> (const_int 64 [0x40])
> ] UNSPEC
thanks, pushed to trunk :)
On Thu, Feb 1, 2024 at 11:02 AM Monk Chiang wrote:
>
> Add sifive p600 series scheduler module. For more information
> see https://www.sifive.com/cores/performance-p650-670.
> Add sifive-p650, sifive-p670 for mcpu option will come in separate patches.
>
> gcc/ChangeLog:
Yeah, that's the plan for the longer term, we would like to build the
schedule model first and then run more benchmarks with that, then
enable dynamic lmul by default, most SiFive cores prefer larger LMUL
if possible/no spill.
On Thu, Feb 1, 2024 at 4:14 PM juzhe.zh...@rivai.ai
wrote:
>
> Thanks.
LGTM :)
On Thu, Feb 1, 2024 at 11:46 PM Juzhe-Zhong wrote:
>
> Realize in recent benchmark evaluation (coremark-pro zip-test):
>
> vid.v v2
> vmv.v.i v5,0
> .L9:
> vle16.v v3,0(a4)
> vrsub.vxv4,v2,a6 ---> LICM failed to hoist it outside the
> loop.
>
>
LGTM :)
On Fri, Feb 2, 2024 at 9:58 AM Juzhe-Zhong wrote:
>
> This patch fixes the following:
>
> vsetvli a5,a1,e32,m1,tu,ma
> sllia4,a5,2
> sub a1,a1,a5
> vle32.v v2,0(a0)
> add a0,a0,a4
> vadd.vv v1,v2,v1
> bne a1,zero,.L3
pushed, thanks :)
On Fri, Feb 2, 2024 at 11:59 AM Monk Chiang wrote:
>
> Add sifive p400 series scheduler module. For more information
> see https://www.sifive.com/cores/performance-p450-470.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.md: Include sifive-p400.md.
> * config/riscv/
pushed, thanks :)
On Fri, Feb 2, 2024 at 11:59 AM Monk Chiang wrote:
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-cores.def: Add sifive-p450, sifive-p670.
> * doc/invoke.texi (RISC-V Options): Add sifive-p450,
> sifive-p670.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.ta
I am not sure it's worth adding a dedicated instruction pattern for
those instructions? In theory those instructions should just be used
by those atomic builin when zabha has enabled, but I think that would
be kinda of a bigger work item.
On Tue, Feb 6, 2024 at 5:18 PM wrote:
>
> From: yulong
>
LGTM, thanks :)
On Wed, Feb 14, 2024 at 10:11 PM Andreas Schwab wrote:
>
> Like AArch64 and POWER, RISC-V does not support trap on zero divide.
>
> gcc/testsuite/
> * gnat.dg/div_zero.adb: Skip on RISC-V.
> ---
> gcc/testsuite/gnat.dg/div_zero.adb | 2 +-
> 1 file changed, 1 insertion(+)
The output of -march=help is like below:
```
All available -march extensions for RISC-V:
NameVersion
i 2.0, 2.1
e 2.0
m 2.0
a 2.0, 2.1
f
Thanks for the test and review, pushed :)
On Thu, Feb 15, 2024 at 6:43 PM Christoph Müllner
wrote:
>
> On Thu, Feb 15, 2024 at 10:56 AM Kito Cheng wrote:
> >
> > The output of -march=help is like below:
> >
> > ```
> > All available -march ext
*sge_ pattern has referenced operand[2] which is
invalid...it should just use `slti` rather than `slti%i2`.
gcc/ChangeLog:
PR target/106543
* config/riscv/riscv.md (*sge_): Fix asm
pattern.
---
gcc/config/riscv/riscv.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
LGTM
On Mon, Feb 19, 2024 at 3:42 PM juzhe.zh...@rivai.ai
wrote:
>
> Ping this patch which is simple fix on VSETVL PASS.
> Ok for trunk ?
>
>
> juzhe.zh...@rivai.ai
>
>
> From: Juzhe-Zhong
> Date: 2024-02-01 17:02
> To: gcc-patches
> CC: kito.cheng; kito.cheng; je
h and without the
> following backport from the trunk, so I'd like to install it in gcc-13.
> Regstrapped on x86_64-linux-gnu, along with other backports, and tested
> manually on riscv64-elf. Ok to install?
>
> From: Kito Cheng
>
> In newer ISA spec, F will implied zicsr, add tha
LGTM, thanks for fixing that issue :)
On Wed, Feb 21, 2024 at 6:03 AM Edwin Lu wrote:
>
> The testcase pr113742.c is failing for 32 bit targets due to the following cc1
> error:
> cc1: error: ABI requries '-march=rv64'
>
> Specify '-march=rv64gc' with '-mtune=sifive-p600-series'
>
> V1: https://g
101 - 200 of 1877 matches
Mail list logo
