Could you add a testcase to make sure zmmul will generate mul instruction?
Liao Shihua 於 2024年5月23日 週四 18:48 寫道：
> Missing boolean_expression TARGET_ZMMUL in riscv_rtx_costs() casuse
> different instructions when multiplying an integer with a constant.
> (
LGTM, thanks for fixing this :)
On Fri, May 17, 2024 at 4:05 PM Xiao Zeng wrote:
>
> According to the description in:
> <https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/367>,
> the type representation symbol of BF16 has been corrected.
>
> Kito Cheng pointed
LGTM
On Thu, May 16, 2024 at 5:09 PM Christoph Müllner
wrote:
>
> The tests cmpmemsi-1.c and cpymemsi-1.c are execution ("dg-do run")
> tests, which does not have any restrictions for the enabled extensions.
> Further, no other listed options are required.
> Let's drop the options, so that the
Hi Xiao Zeng:
Just wondering why use _Bfloat16 rather than __bf16? you mention
__bf16 in comment, but implementation use _Bfloat16? I would like to
use __bf16 to make it consistent between LLVM and psABI if possible :)
Just one minor question
> diff --git a/gcc/testsuite/gcc.target/riscv/cpymemsi-1.c
> b/gcc/testsuite/gcc.target/riscv/cpymemsi-1.c
> index 983b564ccaf..aee54d9aa00 100644
> --- a/gcc/testsuite/gcc.target/riscv/cpymemsi-1.c
> +++ b/gcc/testsuite/gcc.target/riscv/cpymemsi-1.c
> @@ -1,6 +1,5 @@
>
LGTM :)
On Wed, May 15, 2024 at 2:48 PM Christoph Müllner
wrote:
>
> Emitting a DI pattern won't find a match for rv32 and manifests in
> the failing test case gcc.target/riscv/cmo-zicboz-zic64-1.c.
> Let's fix this in the expansion and also address the different
> code that gets generated for
LGTM, I agree we should only implement what Embedded Processor
implies, we have no way to know that from the arch string
On Wed, May 15, 2024 at 1:35 PM Xiao Zeng wrote:
>
> This patch would like to add new sub extension (aka Zvfbfwma) to the
> -march= option. It introduces a new data type
LGTM as well :)
On Sat, May 11, 2024 at 3:58 PM juzhe.zh...@rivai.ai
wrote:
>
> LGTM from my side. Wait for kito chime in.
>
>
> juzhe.zh...@rivai.ai
>
>
> From: pan2.li
> Date: 2024-05-11 15:54
> To: gcc-patches
> CC: juzhe.zhong; kito.cheng; Pan Li
> Subject:
Just found some typo when fixing bugs and then use aspell to find few
more typos, this patch didn't do anything other than fix typo.
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc: Fix typos in comments.
(get_all_predecessors): Ditto.
(pre_vsetvl::m_unknow_info): Rename
Committed to gcc 13 branch, thanks:)
On Tue, May 7, 2024 at 9:20 AM juzhe.zh...@rivai.ai
wrote:
>
> LGTM。
>
>
> juzhe.zh...@rivai.ai
>
>
> From: Kito Cheng
> Date: 2024-05-07 09:17
> To: gcc-patches; kito.cheng; palmer; jeffreyala
vsetvli local eliminate is only consider the current demand instead of
full demand, and it will use that incomplete info to remove vsetvli.
Give following example from PR114747:
vsetvli a5,a1,e8,m4,ta,mu # 57, ratio=2, sew=8, lmul=4
vsetvli zero,a5,e16,m8,ta,ma# 58, ratio=2, sew=16,
Hi Pan:
LGTM.
Hi Jakub:
Is this OK for GCC 14 branch? it's fix ICE on valid code, thanks :)
On Mon, Apr 29, 2024 at 3:40 PM wrote:
>
> From: Pan Li
>
> When we build with isl, there will be a ICE for graphite in both
> the c/c++ and fortran. The legitimize move cannot take care of
> below
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index 0519e0679ed..bad23ea487f 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -2786,6 +2786,44 @@ riscv_v_adjust_scalable_frame (rtx target, poly_int64
> offset, bool epilogue)
>REG_NOTES
OK for trunk, and my understanding is that flag isn't really used in
code gen yet, so it's not necessary to port to GCC 14 branch?
On Mon, Apr 29, 2024 at 7:05 AM Christoph Müllner
wrote:
>
> The extension parsing table entries for a range of Zic* extensions
> does not match the mask definition
LGTM :)
Fangrui Song 於 2024年4月23日 週二 12:27 寫道：
> From: Fangrui Song
>
> --discard-locals (-X) instructs the linker to remove local .L* symbols,
> which occur a lot due to label differences for linker relaxation. The
> arm port has a similar need and passes -X to ld.
>
> In contrast, the RISC-V
LGTM, thanks :)
On Thu, Apr 25, 2024 at 9:26 AM juzhe.zh...@rivai.ai
wrote:
>
> lgtm
>
>
> juzhe.zh...@rivai.ai
>
>
> From: pan2.li
> Date: 2024-04-25 09:25
> To: gcc-patches
> CC: juzhe.zhong; kito.cheng; rdapp.gcc; Pan Li
> Subject: [PATCH v1] RISC-V: Add early
LGTM
juzhe.zh...@rivai.ai 於 2024年4月25日 週四 09:26 寫道：
> lgtm
>
> --
> juzhe.zh...@rivai.ai
>
>
> *From:* pan2.li
> *Date:* 2024-04-25 09:25
> *To:* gcc-patches
> *CC:* juzhe.zhong ; kito.cheng
> ; rdapp.gcc ; Pan Li
>
> *Subject:* [PATCH v1] RISC-V: Add xfail test
thanks, committed :)
On Wed, Apr 24, 2024 at 6:12 PM juzhe.zh...@rivai.ai
wrote:
>
> lgtm.
>
>
> juzhe.zh...@rivai.ai
>
>
> From: Kito Cheng
> Date: 2024-04-24 18:09
> To: gcc-patches; kito.cheng; rdapp; juzhe.zhong
> CC: Kit
LGTM, thanks Pan, although the revert patch series look a little bit
scary, but I believe it's the safest way for now since we don't really
fully understand how register filters work, and it's not really good
timing to figure out all the detail around that.
On Wed, Apr 24, 2024 at 9:02 PM Li,
extract_single_source will recursive checking the sources to
make sure if it's single source, however it may cause infinite
recursive when the source is come from itself, so it should just skip
first source to prevent that.
NOTE: This logic has existing on trunk/GCC 14, but it included in a big
It's simple enough, so LGTM for trunk :)
Fei Gao 於 2024年4月15日 週一 14:38 寫道：
> When one of the two input operands is 0, ADD and IOR are functionally
> equivalent.
> ADD is slightly preferred over IOR because ADD has a higher likelihood
> of being implemented as a compressed instruction when
Does FP reg also need gurared with TARGET_HARD_FLOAT? could you try to
compile that case without F?
On Fri, Apr 12, 2024 at 2:19 PM Li, Pan2 wrote:
>
> Committed, thanks Juzhe.
>
>
>
> Pan
>
>
>
> From: juzhe.zh...@rivai.ai
> Sent: Friday, April 12, 2024 2:11 PM
> To: Li, Pan2 ; gcc-patches
>
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
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
---
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
@@
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
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
>
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)':
>
: 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.
>
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
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
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,
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
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,
> > &, ^, | 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.
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, 2024 9:25 PM
> To: L
> 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: +, -, *, /, %, &, |, ^, >>,
> +
> + /* 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
LGTM too :)
On Mon, Mar 18, 2024 at 11:35 PM Robin Dapp wrote:
>
> LGTM as well.
>
> Regards
> Robin
>
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 :)
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:
>
> *
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
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
lmer 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 atomic
> &
nse 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.
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
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.
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
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
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
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
> >
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
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
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 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
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:
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 that into -ma
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;
*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
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
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
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
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
>
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:
>
> *
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.
> *
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
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.
>
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, 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.
>
>
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])
> ]
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
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
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)")
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
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.
> @@ -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,
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:
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
> style
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
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();
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
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
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:
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
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
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:
*
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
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
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:
> >
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
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
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, 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
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
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:
>
>
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;
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
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 :)
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
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
1 - 100 of 1569 matches
Mail list logo
