于 2025年1月15日 GMT+08:00 下午6:12:34，Xi Ruoyao 写道：
>For things like
>
>(x | 0x101) << 11
>
>It's obvious to write:
>
>ori $r4,$r4,257
>slli.d $r4,$r4,11
>
>But we are actually generating something insane:
>
>
On Thu, 2025-01-16 at 20:52 +0800, Xi Ruoyao wrote:
> On Thu, 2025-01-16 at 20:30 +0800, Lulu Cheng wrote:
> >
> > 在 2025/1/15 下午6:10, Xi Ruoyao 写道:
> > > diff --git a/gcc/config/loongarch/loongarch.cc
> > > b/gcc/config/loongarch/loongarch.cc
> >
On Thu, 2025-01-16 at 20:30 +0800, Lulu Cheng wrote:
>
> 在 2025/1/15 下午6:10, Xi Ruoyao 写道:
> > diff --git a/gcc/config/loongarch/loongarch.cc
> > b/gcc/config/loongarch/loongarch.cc
> > index 9d97f0216f0..3a8e1297bd3 100644
> > --- a/gcc/config/loongarch/loo
tch is correct.
Yes it's correct, having -march=native is at least better than not
having it. I'm just providing some info so if your big.LITTLE user
complains "hey when I bootstrap GCC with BOOT_CFLAGS=-O3 -march=native I
get a comparison error" you can just point they to
On Wed, 2025-01-15 at 13:34 +, Tamar Christina wrote:
>
>
> > -Original Message-
> > From: Xi Ruoyao
> > Sent: Wednesday, January 15, 2025 1:29 PM
> > To: Tamar Christina ; gcc-patches@gcc.gnu.org
> > Cc: nd ; Richard Earnshaw ;
> &g
ee https://gcc.gnu.org/PR111768 for a potential issue.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
For bstrins, we can merge it into and3 instead of having a
separate define_insn.
For bstrpick, we can use the constraints to ensure the first source
register and the destination register are the same hardware register,
instead of emitting a move manually.
This will simplify the next commit where
For things like
(x | 0x101) << 11
It's obvious to write:
ori $r4,$r4,257
slli.d $r4,$r4,11
But we are actually generating something insane:
lu12i.w $r12,524288>>12 # 0x8
ori $r12,$r12,2048
slli.d $r4,$r4,11
or
Our cost model for alsl was wrong: it matches (a + b * imm) where imm is
1, 2, 3, or 4 (should be 2, 4, 8, or 16), and it does not match
(a + (b << imm)) at all. For the test case:
a += c << 3;
b += c << 3;
it caused the compiler to perform a CSE and make one slli and two add,
but we jus
On 64-bit capable LoongArch hardware, alsl.wu is similar to alsl.w but
zero-extending the 32-bit result.
gcc/ChangeLog:
* config/loongarch/loongarch.md (alslsi3_extend): Add alsl.wu.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/alsl_wu.c: New test.
---
gcc/config/loongarch/l
When zbs is not available, there's nothing special with single-bit
immediates and we should perform reassociation as normal immediates.
gcc/ChangeLog:
PR target/115921
* config/riscv/riscv.md (_shift_reverse): Only check
popcount_hwi if !TARGET_ZBS.
---
gcc/config/riscv/r
The test case
long
test (long x, long y)
{
return ((x | 0x1ff) << 3) + y;
}
is now compiled (-O2 -march=rv64g_zba) to
li a4,4096
slliw a5,a0,3
addia4,a4,-8
or a5,a5,a4
addwa0,a5,a1
ret
Despite this check was originally intended t
Each change below is logically intact on its own, they are just in a
series because of a false dependency. Please review separately.
Xi Ruoyao (2):
RISC-V: Improve bitwise and ashift reassociation for single-bit
immediate without zbs [PR 115921]
RISC-V: Remove zba check in bitwise and
_f[];
> diff --git a/gcc/testsuite/gcc.target/loongarch/stack-check-alloca-1.c
> b/gcc/testsuite/gcc.target/loongarch/stack-check-alloca-1.c
> index 6ee589c4b3d..6168461b222 100644
> --- a/gcc/testsuite/gcc.target/loongarch/stack-check-alloca-1.c
> +++ b/gcc/testsuite/gcc.target/loongarch/stack-check-alloca-1.c
> @@ -1,5 +1,5 @@
> /* { dg-do compile } */
> -/* { dg-options "-O2 -fstack-clash-protection --param
> stack-clash-protection-guard-size=16" } */
> +/* { dg-options "-O2 -fstack-clash-protection --param
> stack-clash-protection-guard-size=16 -maddr-reg-reg-cost=1" } */
> /* { dg-require-effective-target supports_stack_clash_protection } */
> /* { dg-require-effective-target alloca } */
> /* { dg-skip-if "" { *-*-* } { "-fstack-check" } { "" } } */
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
anyway.
> + if (val > 0 && !(val & (val - 1)))
> + can_be_optimized = true;
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
(le "") (leu "u")])
> + (le "") (leu "u")
> + (smax "") (umax "u")])
Inconsistent indent.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Wed, 2024-12-18 at 15:09 +0800, Lulu Cheng wrote:
>
> 在 2024/12/16 下午9:19, Xi Ruoyao 写道:
> > A generic CRC optimization pass has been implemented in r15-5850.
> > But
> > without target-specific code, it'll only optimize the CRC loop to a
> > table lookup.
On Tue, 2024-12-17 at 12:52 +0800, Lulu Cheng wrote:
>
> 在 2024/12/17 下午12:30, Xi Ruoyao 写道:
> > On Tue, 2024-12-17 at 11:27 +0800, Lulu Cheng wrote:
> > > 在 2024/12/16 下午9:20, Xi Ruoyao 写道:
> > > /* snip */
> > > > +;; For HImode it's a little
On Tue, 2024-12-17 at 11:27 +0800, Lulu Cheng wrote:
> 在 2024/12/16 下午9:20, Xi Ruoyao 写道:
> /* snip */
> > +;; For HImode it's a little complicated...
> > +(define_expand "rbithi"
> I didn't find rtithi's template description. Are there any test ca
comparison first
+so we can have a != 0 comparison with the result. */
+ if (operands[2] != CONST0_RTX (mode))
+{
+ rtx tmp = gen_reg_rtx (mode);
+ emit_insn (gen_xor3 (tmp, operands[1], operands[2]));
+}
+
+ if (code == NE)
+emit_jump_insn (gen__bnz_v_b (operands[3], tmp, const
QHSD and QHWD are basically the same thing, but QHSD will be incorrect
when we start to add LA32 support. So it's just better to always use
QHWD.
gcc/ChangeLog:
* config/loongarch/loongarch.md (QHSD): Remove.
(loongarch__w__w): Use QHSD instead of QHWD.
(loongarch__w__w_e
gcc/testsuite/ChangeLog:
* g++.target/loongarch/crc.C: New test.
* g++.target/loongarch/crc-scan.C: New test.
---
gcc/testsuite/g++.target/loongarch/crc-scan.C | 13 ++
gcc/testsuite/g++.target/loongarch/crc.C | 113 ++
2 files changed, 126 insertions(+)
cre
LoongArch supports native bit reverse operation for QI, SI, DI, and for
HI we can expand it into a shift and a bit reverse in word_mode.
I was reluctant to add them because until PR50481 is fixed these
operations will be just useless. But now it turns out we can use them
to optimize the bit rever
64-bit LoongArch has native CRC instructions for two specific
polynomials. For other polynomials or 32-bit, use the generic
table-based approach but optimize bit reversing.
gcc/ChangeLog:
* config/loongarch/loongarch.md (crc_revsi4): New
define_expand.
---
gcc/config/loongarch/l
For a textbook-style CRC implementation:
uint32_t crc = 0xu;
for (size_t k = 0; k < len; k++)
{
crc ^= data[k];
for (int i = 0; i < 8 * sizeof (T); i++)
if (crc & 1)
crc = (crc >> 1) ^ poly;
else
crc >>= 1;
}
e can directly invoke the hardware instruction; even if a
hardware instruction isn't available, we can still use LoongArch bit
reversion instructions to optimize the bit reverse before looking up the
table.
Xi Ruoyao (5):
LoongArch: Remove QHSD and use QHWD instead
LoongArch: Add bit reverse
ll in early development and it's not useful for compiling
any real rust programs.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
mpile } */
> > -/* { dg-options "-fdump-tree-crc-details -w" } */
> > +/* { dg-options "-O2 -fdump-tree-crc-details -w" } */
> > /* { dg-skip-if "" { *-*-* } { "-O0" "-O1" "-Os" "-O3" "-flto" }
on't do that.
AFAIK --no-verbose just cancels out a prior --verbose and it's not same
as --quiet. I.e. there are 3 different console output levels, --quiet,
--no-verbose (the default), and --verbose.
Try "curl --verbose example.org -Lo /dev/null", "curl example.org -Lo
/dev/null", and "curl --silent example.org -Lo /dev/null" yourself.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
flto" } } */
No, the current consensus is moving them from gcc.dg to gcc.dg/torture.
to fix the issue. See
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/670619.html.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Wed, 2024-11-27 at 14:24 +0800, Lulu Cheng wrote:
>
> 在 2024/11/27 下午12:06, Xi Ruoyao 写道:
> > On Wed, 2024-11-27 at 11:58 +0800, Lulu Cheng wrote:
> > > > > --- /dev/null
> > > > > +++
> > > > > b/gcc/testsuite/gcc.target/loongarch/vec
} */
instead of
/* { dg-do compile } */
and then if the issue wasn't fixed we'd get an assembler error, thus we
no longer need write many scan-assembler directives to check if the
issue is fixed.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
; + return loongarch_const_vector_same_int_p (op, mode);
> })
>
> (define_predicate "par_const_vector_shf_set_operand"
> @@ -663,6 +663,6 @@
> (ior (match_operand 0 "register_operand")
> (match_operand 0 "const_vector_same_ximm5_operand")))
>
> -(define_predicate "reg_or_vector_same_uimm6_operand"
> +(define_predicate "reg_or_vector_same_uimm_operand"
> (ior (match_operand 0 "register_operand")
> - (match_operand 0 "const_vector_same_uimm6_operand")))
> + (match_operand 0 "const_vector_same_uimm_operand")))
> diff --git
> a/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-shift-sameimm-vec.c
> b/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-shift-sameimm-vec.c
> new file mode 100644
> index 000..73df6217c63
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-shift-sameimm-vec.c
> @@ -0,0 +1,72 @@
> +/* Test shift bits overflow in vector */
> +/* { dg-do compile } */
> +/* { dg-options "-mlasx -O2" } */
> +/* { dg-final { scan-assembler "xvslli.b.*,1" } } */
Am I correct that the issue has triggered an assembler error? IIUC we
can change it to "dg-do assemble" and then we don't need to have all
those scan-assembler.
/* snip */
> diff --git
> a/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-shift-sameimm-vec.c
> b/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-shift-sameimm-vec.c
> new file mode 100644
> index 000..68e89e941e4
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-shift-sameimm-vec.c
> @@ -0,0 +1,72 @@
> +/* Test shift bits overflow in vector */
> +/* { dg-do compile } */
> +/* { dg-options "-mlsx -O2" } */
> +/* { dg-final { scan-assembler "vslli.b.*,1" } } */
Likewise.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Sun, 2024-11-24 at 14:12 -0500, John David Anglin wrote:
> I don't see any regressions with this change. Patch is okay
> if you remove declaration of pa_section_type_flags in pa.cc.
Pushed https://gcc.gnu.org/r15-5641 with the declaration of
pa_section_type_flags removed.
--
It's no longer needed since r15-4842 (when the target-independent code
started to handle the case).
gcc/ChangeLog:
* config/pa/pa.cc (pa_section_type_flags): Remove.
(TARGET_SECTION_TYPE_FLAGS): Remove.
---
I don't have a hppa machine to test this, but conceptually this should
be
tomake 1.15.1 from Makefile.am.
> +# Makefile.in generated by automake 1.16.1 from Makefile.am.
You cannot use a random automake version. Please use the version
specified in https://gcc.gnu.org/install/prerequisites.html.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
the last patch, separately
> from the series so that you don't need to repeat it any time git rebase
> is needed before pushing).
IIUC 4/4 shouldn't be in LOCAL_PATCHES? It modifies our own test case,
not from the upstream.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
able to bypass
> > > > pass_align_tight_loops in
> > zhaoxin.
> > > >
> > > > Bootstrapped X86_64.
> > > > Ok for trunk?
> LGTM.
I'd suggest to add the reference to PR 117438 into the subject and
ChangeLog.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Sat, 2024-11-02 at 16:38 +0800, Xi Ruoyao wrote:
> The patch at [1] changes these builtins to accept unsigned vector
> arguments to be consistent with other LSX/LASX bitwise builtins, but
> there's some concern about the backward compatibility. Make use of the
> existing
On Sat, 2024-11-02 at 09:52 +0800, Lulu Cheng wrote:
>
> 在 2024/11/2 上午1:36, Xi Ruoyao 写道:
> > Without optimization, GCC does not emit a jump table for the test case.
> >
> > I'm not sure if the test case has been wrong in the first place or
> > something has
On Sat, 2024-11-02 at 14:26 +0800, Xi Ruoyao wrote:
> On Sat, 2024-11-02 at 14:13 +0800, Lulu Cheng wrote:
> >
> > 在 2024/11/2 上午1:10, Xi Ruoyao 写道:
> > > On Thu, 2024-10-31 at 23:58 +0800, Xi Ruoyao wrote:
> > >
> > > /* snip */
> > >
The patch at [1] changes these builtins to accept unsigned vector
arguments to be consistent with other LSX/LASX bitwise builtins, but
there's some concern about the backward compatibility. Make use of the
existing built-in function overloading mechanism to provide the backward
compatibility.
Dep
On Sat, 2024-11-02 at 14:13 +0800, Lulu Cheng wrote:
>
> 在 2024/11/2 上午1:10, Xi Ruoyao 写道:
> > On Thu, 2024-10-31 at 23:58 +0800, Xi Ruoyao wrote:
> >
> > /* snip */
> >
> > > ---
> > >
> > > Now running bootstrap & regtest. Posted
On Fri, 2024-11-01 at 11:41 -0600, Jeff Law wrote:
>
>
> On 11/1/24 11:16 AM, Xi Ruoyao wrote:
> > How can you use "read-shared" as an identifier? It's not allowed by
> > all
> > C standard versions.
> >
> > gcc/testsuite/ChangeLog:
>
Without optimization, GCC does not emit a jump table for the test case.
I'm not sure if the test case has been wrong in the first place or
something has changed in these months...
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/jump-table-annotate.c
(dg-additional-options): Add -
On Tue, 2024-10-29 at 07:49 -0600, Jeff Law wrote:
>
>
> On 10/29/24 7:10 AM, Xi Ruoyao wrote:
> > On Fri, 2024-10-11 at 02:54 +0800, Xi Ruoyao wrote:
> > > At least two ports (hppa and loongarch) need to set SECTION_RELRO for
> > > .data.rel.ro{,.local} i
How can you use "read-shared" as an identifier? It's not allowed by all
C standard versions.
gcc/testsuite/ChangeLog:
* gcc.c-torture/execute/builtin-prefetch-1.c (rws): Use
"read_shared" instead of "read-shared" as the identifier for
enum value.
* gcc.dg/builtin-
On Thu, 2024-10-31 at 23:58 +0800, Xi Ruoyao wrote:
/* snip */
> ---
>
> Now running bootstrap & regtest. Posted early as a context for some
> LLVM patch. I'll post the regtest result once it finishes.
Done, no regressions.
The LLVM patch is https://github.com/llvm/llv
this issue).
> (Note: some platforms may use UTF-8 for the C locale; there's support in
> the testsuite for using C.ASCII instead on Cygwin for that reason. This
> matters if you're testing the use of ASCII versus Unicode quotes in
> diagnostics.)
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
;: expected KEY=VALUE-style parameter for
format `foo' after `:'; got `'
"
val2="PROGNAME: error: `-fOPTION=foo:': expected KEY=VALUE-style parameter for
format `foo' after `:'; got `'
"
("错误" just means "error" in Chinese.)
I'm not sure what the best way is to fix the issue.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Align them with other vector bitwise builtins.
This may break programs directly invoking __builtin_lsx_vorn_v or
__builtin_lasx_xvorn_v, but doing so is not supported (as builtins are
not documented, only intrinsics are documented and users should use them
instead).
gcc/ChangeLog:
* conf
On Fri, 2024-10-11 at 02:54 +0800, Xi Ruoyao wrote:
> At least two ports (hppa and loongarch) need to set SECTION_RELRO for
> .data.rel.ro{,.local} in section_type_flags (PR52999 and PR116887), and
> I cannot see a reason not to just set it in the generic code.
>
> With this appl
common.opt: ...
gcc/cobol/ChangeLog:
* lang.opt: ...
* ...
And you need to add a stub gcc/cobol/ChangeLog before the patch, like
commit 24ff0b3e0c41e3997fb4c11736b8a412afbaadf3 "Add stub
'gcc/rust/ChangeLog'".
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
At least two ports (hppa and loongarch) need to set SECTION_RELRO for
.data.rel.ro{,.local} in section_type_flags (PR52999 and PR116887), and
I cannot see a reason not to just set it in the generic code.
With this applied we can also remove the hppa-specific
pa_section_type_flags in a future patch
On Mon, 2024-10-07 at 20:37 +0800, Xi Ruoyao wrote:
> On Mon, 2024-10-07 at 14:25 +0200, Jakub Jelinek wrote:
> > On Mon, Oct 07, 2024 at 03:05:56PM +0300, Дилян Палаузов wrote:
> > > does [[noreturn]] optimize the generated [[noreturn]] function itself, or
> > > it
.
Technically it also turns the return statements in the function body
into __builtin_unreachable(), if we call this an "optimization." In C++
it's done for non-void function even without [[noreturn]] as allowed by
the C++ standard.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Thu, 2024-09-19 at 10:21 -0400, Jason Merrill wrote:
/* snip */
> Another possibility would be to just say GCC 5, and adjust that upward
> if we run into problems.
I'd remind that GCC 5.1 is known as incapable to bootstrap recent GCC
releases due to PR 65801.
--
Xi Ruo
On Wed, 2024-09-11 at 16:17 +0800, 梅杰 wrote:
> 在 2024/9/10 17:30, Xi Ruoyao 写道:
> > On Tue, 2024-09-10 at 16:50 +0800, 梅杰 wrote:
> > > As for the function `__builtin_rint`, although it exists, however, after
> > > defining the instruction in `mips.md`, GCC still won&
>= 6"
+ "rint.\t%0,%1")
+
+
;; Synchronization instructions.
it works for me:
$ cat t.c
double test(double x)
{
return __builtin_rint(x);
}
$ ./gcc/cc1 t.c -nostdinc -O2 -mips64r6 -mexplicit-relocs -mabi=64
$ grep rint t.s
rint.d $f0,$f12
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
on of https://gcc.gnu.org/contribute.html for
how to refer to a PR correctly, instead of putting an URL here.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
cuit=1 was actually faster than the code
generated with -Ofast --param logical-op-non-short-circuit=0.
AFAIK 2 isn't an issue for RISC-V (where FP comparison result is just in
GPR) but 1 and 3 may still need to be considered.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
;
}
is compiled to:
test:
li a5,1048576
sllia0,a0,12
and a0,a0,a5
ret
So why must we spend an instruction to load the single-bit immediate?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
After fixing PR116142 some code started to trigger an ICE with -O3
-march=znver4. Per Richard Biener who actually made this fix:
"supportable_widening_operation fails at transform time - that's likely
because vectorizable_reduction "puns" defs to internal_def"
so the check should use STMT_VINFO_
fixed.
Pushed r15-2931. The ranger is already fixed at r15-2924. The
redundant andi is fixed at r15-2426.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Wed, 2024-07-31 at 21:58 +, Joseph Myers wrote:
> On Mon, 22 Jul 2024, Xi Ruoyao wrote:
>
> > On Mon, 2024-05-06 at 12:45 +0800, Xi Ruoyao wrote:
> > > In GCC 14.1-rc1, there are two new (comparing to GCC 13) failures if
> > > the build is configured --enabl
f a patch posted on the
list breaks aarch64. It complained some of my patches and I fixed them
before commit. Why this case was not caught?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Wed, 2024-08-07 at 07:01 +0100, Sam James wrote:
> Xi Ruoyao writes:
>
> > The check was implemented incorrectly, so
> > vec_widen_smult_{even,odd}_M
> > was never used. This is not good for targets with native even/odd
> > widening multiplication but not lo/h
The check was implemented incorrectly, so vec_widen_smult_{even,odd}_M
was never used. This is not good for targets with native even/odd
widening multiplication but not lo/hi multiplication.
The fix is actually developed by Richard Biener.
gcc/ChangeLog:
PR tree-optimization/116142
On Wed, 2024-07-31 at 16:57 +0800, Lulu Cheng wrote:
>
> 在 2024/7/29 下午3:58, Xi Ruoyao 写道:
> > Per a gcc-help thread we are generating sub-optimal code for
> > __builtin_bswap{32,64}. To fix it:
> >
> > - Use a single revb.d instruction for bswapdi2.
> > -
In r15-1207 I was too stupid to realize we just need to relax
ins_zero_bitmask_operand to allow using bstrins for aligning, instead of
adding a new split. And, "> 12" in ins_zero_bitmask_operand also makes
no sense: it rejects bstrins for things like "x & ~4l" with no good
reason.
So fix my error
Per a gcc-help thread we are generating sub-optimal code for
__builtin_bswap{32,64}. To fix it:
- Use a single revb.d instruction for bswapdi2.
- Use a single revb.2w instruction for bswapsi2 for TARGET_64BIT,
revb.2h + rotri.w for !TARGET_64BIT.
- Use a single revb.2h instruction for bswapsi2
+1668,7 @@ (define_insn "*norsi3_internal"
> [(set_attr "type" "logical")
> (set_attr "mode" "SI")])
>
> -(define_insn "n"
> +(define_insn "n3"
> [(set (match_operand:X 0 "register_operand" "=r&q
We already had "si3_extend" insns and we hoped the fwprop or combine
passes can use them to remove unnecessary sign extensions. But this
does not always work: for cases like x << 1 | y, the compiler
tends to do
(sign_extend:DI
(ior:SI (ashift:SI (reg:SI $r4)
(co
On Sun, 2024-07-21 at 22:46 -0700, Andrew Pinski wrote:
> On Sun, Jul 21, 2024 at 3:57 AM Xi Ruoyao wrote:
> >
> > On Mon, 2024-07-15 at 15:53 +0800, Lulu Cheng wrote:
> > > Hi,
> > >
> > > g++.dg/opt/pr107569.C and range-sincos.c vrp-fl
Ping^6 https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650763.html
I'm quite frustrated why no response to such simple test case fixes.
Are people on vacation or something?
On Mon, 2024-05-06 at 12:45 +0800, Xi Ruoyao wrote:
> In GCC 14.1-rc1, there are two new (comparing to GCC 13)
; function is fixed.
Oops https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656937.html
won't be enough for pr107569.C. For pr107569.C I guess we need to add
range ops for __builtin_isfinite but the patch only handles
__builtin_isinf.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Sat, 2024-07-20 at 07:16 +0100, Sam James wrote:
> Xi Ruoyao writes:
>
> > On Sat, 2024-07-20 at 06:52 +0100, Sam James wrote:
> > > Some distributions like Gentoo make -Wformat and -Wformat-security
> > > enabled by default. Pass -Wno-format to the test to avoid
sns -fno-guess-branch-probability
> -fno-tree-fre -fno-tree-ch -Wno-format" } */
>
> int printf(const char *, ...);
> int a[6], b, c;
>
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Thu, 2024-07-18 at 20:41 +0800, Xi Ruoyao wrote:
> On Thu, 2024-07-18 at 19:54 +0800, Xi Ruoyao wrote:
> > On Tue, 2024-07-09 at 22:29 -0600, Jeff Law wrote:
> > >
> > >
> > > On 7/9/24 8:35 PM, Xi Ruoyao wrote:
> > > > On Mon, 2024-07-08 at 1
On Thu, 2024-07-18 at 19:54 +0800, Xi Ruoyao wrote:
> On Tue, 2024-07-09 at 22:29 -0600, Jeff Law wrote:
> >
> >
> > On 7/9/24 8:35 PM, Xi Ruoyao wrote:
> > > On Mon, 2024-07-08 at 15:03 -0600, Jeff Law wrote:
> > > > So I would use tmp (or
On Tue, 2024-07-09 at 22:29 -0600, Jeff Law wrote:
>
>
> On 7/9/24 8:35 PM, Xi Ruoyao wrote:
> > On Mon, 2024-07-08 at 15:03 -0600, Jeff Law wrote:
> > > So I would use tmp (or another word_mode pseudo register) for the
> > > destination of that
This is per the request from the kernel developers. For generating the
ORC unwind info, the objtool program needs to analysis the control flow
of a .o file. If a jump table is used, objtool has to correlate the
jump instruction with the table.
On x86 (where objtool was initially developed) it's
Doing so can avoid loading FP constants from the memory. It also
partially fixes PR 66462 as fclass does not signal on sNaN.
gcc/ChangeLog:
* config/loongarch/loongarch.md (extendsidi2): Add ("=r", "f")
alternative and use movfr2gr.s for it. The spec clearly states
movfr
This is per the request from the kernel developers. For generating the
ORC unwind info, the objtool program needs to analysis the control flow
of a .o file. If a jump table is used, objtool has to correlate the
jump instruction with the table.
On x86 (where objtool was initially developed) it's
On Wed, 2024-07-10 at 21:54 +0800, Xi Ruoyao wrote:
> On Mon, 2024-07-01 at 09:11 +0800, HAO CHEN GUI wrote:
> > Hi,
> > Gently ping it.
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653096.html
>
> I guess you can add PR114678 into the subject and the Change
On Mon, 2024-07-01 at 09:11 +0800, HAO CHEN GUI wrote:
> Hi,
> Gently ping it.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653096.html
I guess you can add PR114678 into the subject and the ChangeLog, and
also mention the patch in the bugzilla.
--
Xi Ruoyao
School of
lic:
> private:
> auto_vec> m_stack;
> auto_vec m_replacements;
> - const std::pair m_marker = std::make_pair (NULL, NULL);
> + const std::pair m_marker = std::make_pair(nullptr, nullptr);
> };
AFAIK we prefer NULL_TREE for this.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Tue, 2024-07-09 at 20:21 -0600, Jeff Law wrote:
>
>
> On 7/9/24 8:14 PM, Xi Ruoyao wrote:
> > On Tue, 2024-07-09 at 16:10 -0700, Vineet Gupta wrote:
> > > On 7/3/24 21:35, Xi Ruoyao wrote:
> > > > On Sun, 2024-06-30 at 17:47 -0700, Vineet Gupta wrote:
ass.s$f0,$f0
movfr2gr.s $r4,$f0
andi$r12,$r4,136
andi$r13,$r4,952
sltu$r12,$r0,$r12
sltu$r13,$r0,$r13
slli.w $r13,$r13,2
andi$r4,$r4,68
slli.w $r12,$r12,1
or $r12,$r12,$r13
sltu$r4,$r0,$r4
or $r4,$r4,$r12
andi$r4,$r4,7 # < Why we need this?!
jr $r1
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Tue, 2024-07-09 at 16:10 -0700, Vineet Gupta wrote:
> On 7/3/24 21:35, Xi Ruoyao wrote:
> > On Sun, 2024-06-30 at 17:47 -0700, Vineet Gupta wrote:
> > > - Don't hardcode SI in patterns, try to keep X to avoid potential
> > > sign extension pitfalls. Imple
On Tue, 2024-07-09 at 16:33 -0700, Vineet Gupta wrote:
>
>
> On 7/9/24 16:23, Jeff Law wrote:
> >
> > On 7/9/24 5:08 PM, Vineet Gupta wrote:
> > > On 7/3/24 12:08, Xi Ruoyao wrote:
> > > > On Fri, 2024-06-28 at 17:53 -0700, Vineet Gupta wrote:
> &
Ping^5 https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650763.html
On Mon, 2024-05-06 at 12:45 +0800, Xi Ruoyao wrote:
> In GCC 14.1-rc1, there are two new (comparing to GCC 13) failures if
> the build is configured --enable-default-pie. Let's fix them.
>
> Tested on x86_
doc SImode is required. At least the doc should be updated
to say "operand 0 has an integer mode" or something if doing so is
intentionally allowed.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
anyway: https://godbolt.org/z/bnnGf3a38 and the
standards only require a non-zero return value if the input is infinite
(positive or negative).
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
h_cost->movgr2cf;
Then we don't need to check TARGET_uARCH_LA464.
> + }
> + }
> + return cost;
> +}
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
cmp = gen_rtx_NE (SImode, tmp, const0_rtx);
emit_insn (gen_cstoresi4 (operands[0], cmp, tmp, const0_rtx));
DONE;
})
and remove the necessity of UNSPEC_ISFINITE.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Fri, 2024-06-28 at 20:34 +0800, chenglulu wrote:
>
> 在 2024/6/28 下午8:25, Xi Ruoyao 写道:
> > Hi Richard,
> >
> > The late combine pass has triggered some FAILs on LoongArch and I'm
> > investigating. One of them is movcf2gr-via-fr.c. In
> > 315r.
slow.
Could you suggest how to fix this issue?
On Thu, 2024-06-20 at 14:34 +0100, Richard Sandiford wrote:
> This series is a resubmission of the late-combine work. I've fixed
> some bugs that Jeff's cross-target CI found last time and some others
> that I hit since then.
/* s
Ping.
On Sat, 2024-06-15 at 21:47 +0800, Xi Ruoyao wrote:
> The first form has a lower latency (due to the special handling of
> "move" in LA464 and LA664) despite it's longer.
>
> gcc/ChangeLog:
>
> * config/loongarch/loongar
Ping.
On Sun, 2024-06-16 at 01:50 +0800, Xi Ruoyao wrote:
> Consider
>
> c &= 0xfff;
> a &= ~0xfff;
> b &= ~0xfff;
> a |= c;
> b |= c;
>
> This can be done with 2 bstrins instructions. But we need to
> recognize
> it in loongarch
1 - 100 of 1038 matches
Mail list logo
