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
On Tue, 2024-01-16 at 10:57 +0800, chenxiaolong wrote:
> 在 2024-01-15一的 15:50 +0800，Xi Ruoyao写道：
> > On Mon, 2024-01-15 at 15:10 +0800, chenxiaolong wrote:
> > > At 14:42 +0800 on the first day of 2024-01-15, Xi Ruoyao wrote：
> > > > On Mon, 2024-01-15 at 14:32 +0800, YunQiang Su wrote:
> > > > > X
Ping.
On Fri, 2023-12-15 at 20:56 +0800, Xi Ruoyao wrote:
> We don't allow SImode in FCC, so constraint z is never really used
> here.
>
> gcc/ChangeLog:
>
> * config/loongarch/loongarch.md (movsi_internal): Remove
> constraint z.
> ---
>
> Bootstrapped and regtested on loongarch64-
I'm going to check-in this if no objection
Hongyu Wang 于2024年1月9日周二 15:14写道：
>
> Hi,
>
> This patch adds missing description for inline asm behavior and related
> compiler switch for APX.
>
> Ok for gcc-wwwdocs?
>
> ---
> htdocs/gcc-14/changes.html | 6 ++
> 1 file changed, 6 insertions(+)
>
在 2024/1/16 下午1:34, Xi Ruoyao 写道:
Ping.
On Fri, 2023-12-15 at 20:56 +0800, Xi Ruoyao wrote:
We don't allow SImode in FCC, so constraint z is never really used
here.
gcc/ChangeLog:
* config/loongarch/loongarch.md (movsi_internal): Remove
constraint z.
---
Bootstrapped and r
On Tue, 2024-01-16 at 14:16 +0800, chenglulu wrote:
>
>
> 在 2024/1/16 下午1:34, Xi Ruoyao 写道:
> > Ping.
> >
> > On Fri, 2023-12-15 at 20:56 +0800, Xi Ruoyao wrote:
> > > We don't allow SImode in FCC, so constraint z is never really used
> > > here.
> > >
> > > gcc/ChangeLog:
> > >
> > > * conf
在 2024/1/16 下午2:20, Xi Ruoyao 写道:
On Tue, 2024-01-16 at 14:16 +0800, chenglulu wrote:
在 2024/1/16 下午1:34, Xi Ruoyao 写道:
Ping.
On Fri, 2023-12-15 at 20:56 +0800, Xi Ruoyao wrote:
We don't allow SImode in FCC, so constraint z is never really used
here.
gcc/ChangeLog:
* config/loong
Recently notice there is a XPASS in RISC-V:
XPASS: gcc.dg/vect/bb-slp-43.c -flto -ffat-lto-objects scan-tree-dump-not slp2
"vector operands from scalars"
XPASS: gcc.dg/vect/bb-slp-43.c scan-tree-dump-not slp2 "vector operands from
scalars"
And checked both ARM SVE and RVV:
https://godbolt.org/
Notice there is a regression recently:
XPASS: gcc.dg/vect/bb-slp-subgroups-3.c -flto -ffat-lto-objects
scan-tree-dump-times slp2 "optimized: basic block" 2
XPASS: gcc.dg/vect/bb-slp-subgroups-3.c scan-tree-dump-times slp2 "optimized:
basic block" 2
Checked on both ARM SVE an RVV:
https://godbo
On Mon, 15 Jan 2024, Robin Dapp wrote:
> I gave it another shot now by introducing a separate function as
> Richard suggested. It's probably not at the location he intended.
>
> The way I read the discussion there hasn't been any consensus
> on how (or rather where) to properly tackle the proble
On Tue, 16 Jan 2024, Juzhe-Zhong wrote:
> Recently notice there is a XPASS in RISC-V:
> XPASS: gcc.dg/vect/bb-slp-43.c -flto -ffat-lto-objects scan-tree-dump-not
> slp2 "vector operands from scalars"
> XPASS: gcc.dg/vect/bb-slp-43.c scan-tree-dump-not slp2 "vector operands from
> scalars"
>
>
>> That's probably because we have vect_variable_length && vect128 instead?
Yes. Both RVV and SVE uses 128bit vector SLP.
The optimized IR (both ARM SVE and RVV are similiar):
vect__1.5_189 = MEM [(int *)x_50(D)];
vect__1.6_191 = MEM [(int *)x_50(D) + 16B];
mask__2.7_192 = vect__1.5_189 ==
On Tue, 16 Jan 2024, Juzhe-Zhong wrote:
> Notice there is a regression recently:
> XPASS: gcc.dg/vect/bb-slp-subgroups-3.c -flto -ffat-lto-objects
> scan-tree-dump-times slp2 "optimized: basic block" 2
> XPASS: gcc.dg/vect/bb-slp-subgroups-3.c scan-tree-dump-times slp2 "optimized:
> basic block
On Tue, 16 Jan 2024, juzhe.zh...@rivai.ai wrote:
> >> That's probably because we have vect_variable_length && vect128 instead?
> Yes. Both RVV and SVE uses 128bit vector SLP.
>
> The optimized IR (both ARM SVE and RVV are similiar):
> vect__1.5_189 = MEM [(int *)x_50(D)];
> vect__1.6_191 = M
101 - 114 of 114 matches
Mail list logo
