It is not a target specific issue, it will fail if we enabled AVX.
e.g.:
$ /export/users/haochenj/env/build_no_bootstrap_master/gcc/xgcc
-B/export/users/haochenj/env/build_no_bootstrap_master/gcc/
/export/users/haochenj/src/gcc/master/gcc/testsuite/gcc.dg/gnu23-tag-4.c -m64
-mavx
OK. This sub-patch is ok to commit after adding new line to prefix.c
juzhe.zh...@rivai.ai
发件人： joshua
发送时间： 2023-12-25 15:08
收件人： juzhe.zh...@rivai.ai; gcc-patches
抄送： Jim Wilson; palmer; andrew; philipp.tomsich; jeffreyalaw;
christoph.muellner; jinma; cooper.qu
主题： 回复：[PATCH v4 4/6] RISC-V:
+ if (current_output_insn == NULL_RTX)
+ return p;
This is for inline assembly case.
--
发件人：juzhe.zh...@rivai.ai
发送时间：2023年12月25日(星期一) 14:37
收件人："cooper.joshua";
"gcc-patches"
抄 送：Jim Wilson; palmer;
andrew; "philipp.tomsich";
+ if (current_output_insn == NULL_RTX)
+return p;
What is this used for ?
How about:
+ /* We need to add th. prefix to all the xtheadvector
+ insturctions here.*/
+ if (TARGET_XTHEADVECTOR && p[0] == 'v')
+fputs ("th.", asm_out_file);
\ No newline at end of file
New line should
This patch only involves the generation of xtheadvector
special load/store instructions and vext instructions.
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc
(class th_loadstore_width): Define new builtin bases.
(BASE): Define new builtin bases.
*
This patch is to handle the differences in instruction generation
between Vector and XTheadVector. In this version, we only support
partial xtheadvector instructions that leverage directly from current
RVV1.0 with simple adding "th." prefix. For different name xtheadvector
instructions but share
This patch adds th. prefix to all XTheadVector instructions by
implementing new assembly output functions. In this version, we
follow Kito's suggestions and only check the prefix is 'v', so that
no extra attribute is needed.
gcc/ChangeLog:
* config/riscv/riscv-protos.h
gcc/testsuite/ChangeLog:
* gcc.dg/vect/costmodel/riscv/rvv/pr113112-1.c: Add one more ASM check.
---
gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/pr113112-1.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/pr113112-1.c
In the testcase provided, we would match f_plus but not g_plus
due to a missing `:c` on the plus operator. This fixes the oversight
there.
Note this was noted in https://github.com/llvm/llvm-project/issues/76318 .
Committed as obvious after bootstrap/test on x86_64-linux-gnu.
PR
We found that using the latest compiled gcc will cause a miscompare error
when running spec2006 400.perlbench test with -flto turned on. After testing,
it was found that only the LoongArch architecture will report errors.
The first error commit was located through the git bisect command as
在 2023/12/24 下午8:59, Xi Ruoyao 写道:
On Sat, 2023-12-23 at 18:47 +0800, Xi Ruoyao wrote:
On Sat, 2023-12-23 at 18:44 +0800, Xi Ruoyao wrote:
On Sat, 2023-12-23 at 10:29 +0800, chenglulu wrote:
The performance drop has nothing to do with this patch. I found that the h264
performance compiled
Hi All,
This patch was pre-appproved by Richi.
This updates the testsuite and adds more #pragma GCC novector to various tests
that would otherwise vectorize the vector result checking code.
This cleans out the testsuite since the last rebase and prepares for the landing
of the early break
This test needs fma support. It is only available on hppa in PA 2.0.
Tested on hppa-unknown-linux-gnu. Committed to trunk.
Dave
---
hppa: Fix pr110279-1.c on hppa
2023-12-24 John David Anglin
gcc/testsuite/ChangeLog:
* gcc.dg/pr110279-1.c: Add -march=2.0 option on hppa*-*-*.
On Sat, 2023-12-23 at 18:47 +0800, Xi Ruoyao wrote:
> On Sat, 2023-12-23 at 18:44 +0800, Xi Ruoyao wrote:
> > On Sat, 2023-12-23 at 10:29 +0800, chenglulu wrote:
> > > > The performance drop has nothing to do with this patch. I found that
> > > > the h264 performance compiled
> > > > by r14-6787
On Sun, 2023-12-24 at 01:04 +0800, Xi Ruoyao wrote:
> On Sun, 2023-12-24 at 00:56 +0800, Xi Ruoyao wrote:
> > On Sat, 2023-12-23 at 15:00 +0800, chenglulu wrote:
> > > Hi,
> > >
> > > This patch will cause the following tests to fail:
> > >
> > > +FAIL: gcc.dg/vect/pr97081-2.c (internal compiler
gcc/ChangeLog:
* config/loongarch/loongarch.md (rotl3):
New define_expand.
* config/loongarch/simd.md (vrotl3): Likewise.
(rotl3): Likewise.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/rotl-with-rotr.c: New test.
*
> > > What's exceedingly weird is T_N_T_M_P (DImode, SImode) isn't
> > > actually a truncation! The output precision is first, the input
> > > precision is second. The docs explicitly state the output precision
> > > should be smaller than the input precision (which makes sense for
> > >
On Sun, Dec 24, 2023, 01:18 YunQiang Su wrote:
> Roger Sayle 于2023年12月24日周日 16:51写道：
> >
> >
> > > What's exceedingly weird is T_N_T_M_P (DImode, SImode) isn't actually a
> > > truncation! The output precision is first, the input precision is
> second. The docs
> > > explicitly state the
Roger Sayle 于2023年12月24日周日 16:51写道：
>
>
> > What's exceedingly weird is T_N_T_M_P (DImode, SImode) isn't actually a
> > truncation! The output precision is first, the input precision is second.
> > The docs
> > explicitly state the output precision should be smaller than the input
> >
> What's exceedingly weird is T_N_T_M_P (DImode, SImode) isn't actually a
> truncation! The output precision is first, the input precision is second.
> The docs
> explicitly state the output precision should be smaller than the input
> precision
> (which makes sense for truncation).
>
>
Roger Sayle 于2023年12月24日周日 08:49写道：
>
>
> Hi YunQiang (and Jeff),
>
> > MIPS claims TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true
> > based on that the hard register is always sign-extended, but here
> > the hard register is polluted by zero_extract.
>
> I suspect that the bug here is
> > Yes. I also guess so. Any new idea?
> Well, I see multiple intertwined issues and I think MIPS has largely
> mucked this up.
>
> At a high level DI -> SI truncation is not a nop on MIPS64. We must
> explicitly sign extend the value from SI->DI to preserve the invariant
> that SI mode objects
22 matches
Mail list logo
