On Wed, 2023-04-26 at 21:29 +0800, Xi Ruoyao via Gcc-patches wrote:
> >
> > Do you have any questions about the test cases mentioned by
> > Guo
> > Jie? If there is no problem, modify the test case,
> >
> > I think the code can be merged into the mai
On Sat, 2023-04-29 at 12:05 -0600, Jeff Law wrote:
>
>
> On 4/15/23 06:01, Xi Ruoyao via Gcc-patches wrote:
> > This prevents a spurious message building a cross-compiler when
> > target
> > libc is not installed yet:
> >
> > cc1: error: no i
;
> > > > + }
> > > > +}
> >
> > I think the test case cannot fully reflect the optimization effect
> > of
> > the current patch,
> >
> > because even without the patch, -O -fshrink-wrap will still perform
> > architecture independent optimization.
> >
> > This patch considers architecture related registers as finer grained
> > optimization for shrink wrapping,
> >
> > I think a test case like the one below is more suitable:
> >
> >
> > int foo(int x)
> > {
> > if (x)
> > {
> > __asm__ ("":::"s0","s1");
> > return x;
> > }
> >
> > __asm__ ("":::"s2","s3");
> > return 0;
> > }
> >
> > Otherwise LGTM, thanks!
>
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
This commit implements the target macros for shrink wrapping of function
prologues/epilogues shrink wrapping on LoongArch.
Bootstrapped and regtested on loongarch64-linux-gnu. I don't have an
access to SPEC CPU so I hope the reviewer can perform a benchmark to see
if there is real benefit.
gcc/C
embler-times "st\\.h" 1 } } */
> > +/* { dg-final { scan-assembler-times "st\\.b" 1 } } */
> > +
> > +extern char a[], b[];
> > +void test() { __builtin_memcpy(a, b, 15); }
> > diff --git a/gcc/testsuite/gcc.target/loongarch/pr109465-2.c
> > b/gcc/testsuite/gcc.target/loongarch/pr109465-2.c
> > new file mode 100644
> > index 000..703eb951c6d
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/loongarch/pr109465-2.c
> > @@ -0,0 +1,9 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-O2 -mabi=lp64d -mstrict-align" } */
> > +/* { dg-final { scan-assembler-times "st\\.d|stptr\\.d" 1 } } */
> > +/* { dg-final { scan-assembler-times "st\\.w|stptr\\.w" 1 } } */
> > +/* { dg-final { scan-assembler-times "st\\.h" 1 } } */
> > +/* { dg-final { scan-assembler-times "st\\.b" 1 } } */
> > +
> > +extern long a[], b[];
> > +void test() { __builtin_memcpy(a, b, 15); }
> > diff --git a/gcc/testsuite/gcc.target/loongarch/pr109465-3.c
> > b/gcc/testsuite/gcc.target/loongarch/pr109465-3.c
> > new file mode 100644
> > index 000..d6a80659b31
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/loongarch/pr109465-3.c
> > @@ -0,0 +1,12 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-O2 -mabi=lp64d -mstrict-align" } */
> > +
> > +/* Three loop iterations each contains 4 st.b, and 3 st.b after the
> > loop */
> > +/* { dg-final { scan-assembler-times "st\\.b" 7 } } */
> > +
> > +/* { dg-final { scan-assembler-not "st\\.h" } } */
> > +/* { dg-final { scan-assembler-not "st\\.w|stptr\\.w" } } */
> > +/* { dg-final { scan-assembler-not "st\\.d|stptr\\.d" } } */
> > +
> > +extern char a[], b[];
> > +void test() { __builtin_memcpy(a, b, 15); }
>
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Tue, 2023-04-18 at 20:03 +0800, Lulu Cheng wrote:
>
> 在 2023/4/18 下午7:48, Xi Ruoyao 写道:
> > On Tue, 2023-04-18 at 19:21 +0800, Lulu Cheng wrote:
> > > 在 2023/4/18 下午5:27, Xi Ruoyao 写道:
> > > > On Mon, 2023-04-10 at 17:45 +0800, Lulu Cheng wrote:
> > >
esult comes out, this patch will
>
> not be merged into the main branch for the time being.
Ok, I'll wait for the result.
>
> Thanks!
>
> 在 2023/4/18 下午8:17, Xi Ruoyao 写道:
> > According to Xuerui's LLVM changeset [1], doing so can make a
> > signif
On Tue, 2023-04-18 at 20:51 +0800, WANG Xuerui wrote:
>
> On 2023/4/18 20:45, Xi Ruoyao wrote:
> > On Tue, 2023-04-18 at 20:39 +0800, WANG Xuerui wrote:
> > > Hi,
> > >
> > > Thanks for helping confirming on GCC and porting this! I'd never know
&
On Tue, 2023-04-18 at 20:39 +0800, WANG Xuerui wrote:
> Hi,
>
> Thanks for helping confirming on GCC and porting this! I'd never know
> even GCC lacked this adaptation without someone actually checking... Too
> many things are taken for granted these days.
>
> On
According to Xuerui's LLVM changeset [1], doing so can make a
significant performace gain.
Bootstrapped and regtested on loongarch64-linux-gnu. Ok for GCC 14?
[1]:https://reviews.llvm.org/D148622
gcc/ChangeLog:
* config/loongarch/loongarch.cc
(loongarch_option_override_internal
On Tue, 2023-04-18 at 19:21 +0800, Lulu Cheng wrote:
>
> 在 2023/4/18 下午5:27, Xi Ruoyao 写道:
> > On Mon, 2023-04-10 at 17:45 +0800, Lulu Cheng wrote:
> > > Sorry, it's my question. I still have some questions that I haven't
> > > understood, so I haven
various testcases (including extracting aggregates and
floating-point values in the va list) and the result seems correct. And
gcc/testsuite/gcc.c-torture/execute/va-arg-*.c should provide a good
enough test coverage.
Is there still something seemly problematic?
>
> 在 2023/4/10 下午5:04, Xi Ruoya
Pushed r14-19.
On Tue, 2023-04-04 at 17:09 +0800, Lulu Cheng wrote:
>
> 在 2023/4/4 下午4:38, Xi Ruoyao 写道:
> > 1. Use addu16i.d for TARGET_64BIT and suitable immediates.
> > 2. Split one addition with immediate into two addu16i.d or
> > addi.{d/w}
> > instruction
On Tue, 2023-04-18 at 09:54 +0800, Lulu Cheng wrote:
> Pushed to r14-15.
>
> Due to my reasons, this modification did not catch up with the creation
> of the releases/gcc-13 branch,
>
> can I still submit this modification to releases/gcc-13?:-(
I guess we need a decision f
+
> #undef MUSL_DYNAMIC_LINKER
> #define MUSL_DYNAMIC_LINKER \
> - "/lib" ABI_GRLEN_SPEC "/ld-musl-loongarch-" ABI_SPEC ".so.1"
> + "/lib/ld-musl-loongarch" ABI_GRLEN_SPEC MUSL_ABI_SPEC ".so.1"
>
> #undef GNU_USER_TARGET_LINK_SPEC
> #define GNU_USER_TARGET_LINK_SPEC \
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
This prevents a spurious message building a cross-compiler when target
libc is not installed yet:
cc1: error: no include path in which to search for stdc-predef.h
As stdc-predef.h was added to define __STDC_* macros by libc, it's
unlikely the header will ever contain some bad definitions w/o
. */
>
> #define BRANCH_COST(speed_p, predictable_p) loongarch_branch_cost
> -#define LOGICAL_OP_NON_SHORT_CIRCUIT 0
>
> /* Return the asm template for a conditional branch instruction.
> OPCODE is the opcode's mnemonic and OPERANDS is the asm template for
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
We'd been generating really bad block move sequences which is recently
complained by kernel developers who tried __builtin_memcpy. To improve
it:
1. Take the advantage of -mno-strict-align. When it is set, set mode
size to UNITS_PER_WORD regardless of the alignment.
2. Half the mode size when
Ping. Or maybe I've lost some replies here because my mail server
crashed several days ago :).
On Wed, 2023-03-29 at 02:01 +0800, Xi Ruoyao wrote:
> LoongArch backend used to save all GARs for a function with variable
> arguments. But sometimes a function only accepts variable argu
__csrxchg_d (u64, u64, imm0_16383)
> +
> + u8 __iocsrrd_b (u32)
> + u16 __iocsrrd_h (u32)
> + u32 __iocsrrd_w (u32)
> + u64 __iocsrrd_d (u32)
> + void __iocsrwr_b (u8, u32)
> + void __iocsrwr_h (u16, u32)
> + void __iocsrwr_w (u32, u32)
> + void __iocsrwr_d (u64, u32)
> +
> + void __dbar (imm0_32767)
> + void __ibar (imm0_32767)
> +
> + void __syscall (imm0_32767)
> + void __break (imm0_32767)
> +@end smallexample
> +
> @node MIPS DSP Built-in Functions
> @subsection MIPS DSP Built-in Functions
>
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Tue, 2023-04-04 at 16:00 +0800, Xi Ruoyao via Gcc-patches wrote:
> On Tue, 2023-04-04 at 11:01 +0800, Lulu Cheng wrote:
>
> /* snip */
>
> > > +unsigned long f10 (unsigned long x) { return x - 0x8000l * 2; }
> > > +unsigned long f11 (unsigned long x
1. Use addu16i.d for TARGET_64BIT and suitable immediates.
2. Split one addition with immediate into two addu16i.d or addi.{d/w}
instructions if possible. This can avoid using a temp register w/o
increase the count of instructions.
Inspired by https://reviews.llvm.org/D143710 and
https://re
ot; in the prologue and
"addu16i.d $r3,$r3,2" in the epilogue, so we can avoid using r14/r13.
I'll try modifying loongarch_expand_{pro,epi}logue for this.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
1. Use addu16i.d for TARGET_64BIT and suitable immediates.
2. Split one addition with immediate into two addu16i.d or addi.{d/w}
instructions if possible. This can avoid using a temp register w/o
increase the count of instructions.
Inspired by https://reviews.llvm.org/D143710 and
https://re
LoongArch backend used to save all GARs for a function with variable
arguments. But sometimes a function only accepts variable arguments for
a purpose like C++ function overloading. For example, POSIX defines
open() as:
int open(const char *path, int oflag, ...);
But only two forms are actu
On Tue, 2023-03-28 at 08:35 +0200, Richard Biener wrote:
> On Mon, Mar 27, 2023 at 8:00 PM Xi Ruoyao via Gcc-patches
> wrote:
> >
> > memmem is not POSIX so the system may lack it. Then libiberty will
> > provide an implementation, but it's a "supplemental
memmem is not POSIX so the system may lack it. Then libiberty will
provide an implementation, but it's a "supplemental function" and not
declared in libiberty.h. We need to declare the prototype to use it
then.
See libiberty doc at
https://gcc.gnu.org/onlinedocs/libiberty/Supplemental-Functions.
iving a
> > version number seems better than "next release"), but "will be deprecated"
> > is odd.
> How about the following:
>
> +Please use warning option @option{-Wgnu-variable-sized-type-not-at-end} to
> +identify all such cases in the source code and modify them. This warning
> will be
> + on by default starting from GCC14.
I'm wondering why it *was" not on by default...
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
o for it?
It's not supported by all GNU assembler releases. For example, GCC
installation doc says we require Binutils >= 2.13.1 for i?86-*-linux*.
Binutils 2.13.1 was released in 2002, but @FILE support was added into
Binutils in 2005.
> >
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
nd-email instead. I stupidly don't understand
> how to use them, so I was making my patches manually...
Or adjust the mail client correctly. You can send the patch to yourself
first and see if it's not "mangled" by the mail client when you debug
such an issue...
But when you fi
On Mon, 2023-03-20 at 00:30 -0700, Ken Matsui wrote:
> I see. Thank you!
Please continue to read. I guess you missed some inline comments from
me...
>
> On Mon, Mar 20, 2023 at 12:26 AM Xi Ruoyao wrote:
> >
> > You need to CC libstd...@gcc.gnu.org for any patches
CXX_BEGIN_NAMESPACE_VERSION
> struct is_reference<_Tp&&>
> : public true_type
> { };
> +#endif
>
> /// is_arithmetic
> template
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Already approved in bugzilla and bootstrapped on x86_64-linux-gnu.
Pushed.
expand_simple_binop() is allowed to allocate a new pseudo-register and
return it, instead of forcing the result into the provided
pseudo-register. This can cause a problem when we expand the unrolled
loop for __builtin_str
On Mon, 2023-03-13 at 12:58 +0800, Lulu Cheng wrote:
>
> 在 2023/3/13 下午12:54, Xi Ruoyao 写道:
> > On Mon, 2023-03-13 at 12:40 +0800, WANG Xuerui wrote:
> > > This is ugly. The fact all current LA32 models don't support CRC
> > > ops is
> > > just a coin
> ops require anything wider than 32 bits, after all.
Maybe the correct way would be adding a switch like MIPS -mcrc or x86
-mcrc32.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
ts for arguments are not needed; the casts
for the return value may be needed to suppress -Wconversion if
__builtin_loongarch_crc_w_d_w does not return an int, but why not change
__builtin_loongarch_crc_w_d_w to return int then?)
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Thu, 2023-03-02 at 10:26 +, Richard Sandiford wrote:
> Xi Ruoyao writes:
> > Hi,
> >
> > This patch series fixes a lot of test failures with --enable-default-pie
> > or --enable-default-ssp for AArch64 target. Only test files are changed
> > to d
al { scan-assembler "addi.d\t\\\$r3,\\\$r3,-16" } } */
The first patch contains this hunk. It's r13-6501 now.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Mon, 2023-03-06 at 13:59 +0800, Xi Ruoyao via Gcc-patches wrote:
> On Mon, 2023-03-06 at 11:16 +0800, Xi Ruoyao wrote:
>
> /* snip */
>
> > > > Sorry for the late reply, the first patch I think is fine. But I
> > > > haven't
> >
Pushed r13-6500 and r12-9225.
On Mon, 2023-03-06 at 15:21 +0800, Lulu Cheng wrote:
>
> 在 2023/3/3 下午4:16, Xi Ruoyao 写道:
> > In the toolchain convention, we describe -mfpu= as:
> >
> > "Selects the allowed set of basic floating-point instructions and
> > regis
On Mon, 2023-03-06 at 11:16 +0800, Xi Ruoyao wrote:
/* snip */
> > > Sorry for the late reply, the first patch I think is fine. But I haven't
> > > reproduced the problem of the second mail.
> > >
> > > Is there any special option in the configuration
it send-email" which is much easier to be correctly
configured.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Mon, 2023-03-06 at 10:48 +0800, Xi Ruoyao wrote:
> On Mon, 2023-03-06 at 09:15 +0800, Lulu Cheng wrote:
> >
> > 在 2023/3/6 上午12:21, Xi Ruoyao 写道:
> > > On Fri, 2023-03-03 at 08:21 -0800, Mike Stump wrote:
> > > > On Mar 3, 2023, at 12:40 AM, Xi R
On Mon, 2023-03-06 at 09:15 +0800, Lulu Cheng wrote:
>
> 在 2023/3/6 上午12:21, Xi Ruoyao 写道:
> > On Fri, 2023-03-03 at 08:21 -0800, Mike Stump wrote:
> > > On Mar 3, 2023, at 12:40 AM, Xi Ruoyao via Gcc-patches
> > > wrote:
> > > > Some trivial test cas
On Fri, 2023-03-03 at 08:21 -0800, Mike Stump wrote:
> On Mar 3, 2023, at 12:40 AM, Xi Ruoyao via Gcc-patches
> wrote:
> >
> > Some trivial test case fixes. Ok for trunk?
>
> Ok.
Lulu: if you don't object I'll push these two in this week.
I tried to bisect
8
> + 2008-2023
>
>
> http://www.w3.org/1999/xlink";
> xlink:href="https://www.fsf.org";>FSF
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
ning it in the ChangeLog). I guess
you need to contribute the libgo part into the upstream Go runtime or
the change will be undone when Ian merges libgo next time.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Fri, 2023-03-03 at 16:54 +0800, Xi Ruoyao wrote:
> The driver emits a warning when -fstack-check and
> -fstack-clash-protection are used together, but the message refers to
> "-fstack-clash_protection" (underline instead of dash).
Forgot: Ok for trunk? Though I think it&
The driver emits a warning when -fstack-check and
-fstack-clash-protection are used together, but the message refers to
"-fstack-clash_protection" (underline instead of dash).
gcc/ChangeLog:
* toplev.cc (process_options): Fix the spelling of
"-fstack-clash-protection".
---
gcc/to
Once upon the time we used to save two registers unnecessarily, costing
16 bytes. Now the issue seems fixed (not sure by which commit though),
adjust the stack offsets to reflex the change.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/stack-check-cfa-1.c (dg-final): Adjust
exp
Stack protector will affect stack layout and break the expectation of
these tests, causing test failures if GCC is configured with
--enable-default-ssp.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/prolog-opt.c (dg-options): Add
-fno-stack-protector.
* gcc.target/loonga
Some trivial test case fixes. Ok for trunk?
Xi Ruoyao (2):
LoongArch: testsuite: Disable stack protector for some tests
LoongArch: testsuite: Adjust stack offsets in stack-check-cfa tests
gcc/testsuite/gcc.target/loongarch/prolog-opt.c| 2 +-
gcc/testsuite/gcc.target/loongarch
In the toolchain convention, we describe -mfpu= as:
"Selects the allowed set of basic floating-point instructions and
registers. This option should not change the FP calling convention
unless it's necessary."
Though not explicitly stated, the rationale of this rule is to allow
combinations like "
new command line option -mriscv_vector_lmul
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-protos.h (riscv_classify_vlmul_field):
The change log entries should be indented with one tab, not some
whitespaces.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
ake things much simpler and aligns with my gut feeling :). I
can drop the change in loongarch-opts.cc now. And the smaller changeset
also makes me more confident about a backport to gcc-12.
V2 patch is being tested and I'll send it after the testing. Meanwhile
I created PR109000 to track th
In the toolchain convention, we describe -mfpu= as:
"Selects the allowed set of basic floating-point instructions and
registers. This option should not change the FP calling convention
unless it's necessary."
Though not explicitly stated, the rationale of this rule is to allow
combinations like "
Stack protector needs a guard value on the stack and change the stack
layout. So we need to disable it for those tests, to avoid test failure
with --enable-default-ssp.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/shrink_wrap_1.c (dg-options): Add
-fno-stack-protector.
*
Stack protector influence code generation and cause function body checks
fail.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/pr103147-10.c (dg-options): Add
-fno-stack-protector.
* g++.target/aarch64/pr103147-10.C: Likewise.
---
gcc/testsuite/g++.target/aarch64/pr103147-1
These tests set large code model with -mcmodel=large or target pragma for
AArch64. But if GCC is configured with --enable-default-pie, it triggers
"sorry: unimplemented: code model large with -fpic". Disable PIE to make
avoid the issue.
gcc/testsuite/ChangeLog:
PR testsuite/70150
Storing stack guarding variable need one stp instruction, breaking the
scan-assembler-not pattern in the test. Disable stack protector to
avoid a test failure with --enable-default-ssp.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/pr104005.c (dg-options): Add
-fno-stack-protecto
In PIE, symbol "fixed_regs" is addressed via GOT. It will break the
scan-assembler pattern and cause test failure with --enable-default-pie.
gcc/testsuite/ChangeLog:
PR testsuite/70150
* gcc.target/aarch64/fuse_adrp_add_1.c (dg-options): Add
-fno-pie.
---
gcc/testsuite/g
The test scans for "const_int 0" in the RTL dump, but stack protector
can produce more "const_int 0". To avoid a failure with
--enable-default-ssp, disable stack protector for this.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/auto-init-7.c (dg-options): Add
-fno-stack-protector
If GCC is configured with --enable-default-ssp, the stack protector can
make many sve-pcs tests fail.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/sve/pcs/aarch64-sve-pcs.exp (sve_flags):
Add -fno-stack-protector.
---
.../gcc.target/aarch64/sve/pcs/aarch64-sve-pcs.exp |
If GCC is built with --enable-default-pie, a lot of aapcs64 tests fail
because relocation unsupported in PIE is used.
gcc/testsuite/ChangeLog:
PR testsuite/70150
* gcc.target/aarch64/aapcs64/aapcs64.exp (additional_flags):
Add -fno-pie -no-pie.
---
gcc/testsuite/gcc.targe
for trunk?
Xi Ruoyao (8):
aarch64: testsuite: disable PIE for aapcs64 tests [PR70150]
aarch64: testsuite: disable PIE for tests with large code model
[PR70150]
aarch64: testsuite: disable PIE for fuse_adrp_add_1.c [PR70150]
aarch64: testsuite: disable stack protector for sve-pcs tests
mp; defined (__LP64__)
> # define TRY_EMPTY_VM_SPACE0x10
> #elif defined(__loongarch__) && defined(__LP64__)
> -# define TRY_EMPTY_VM_SPACE0x80
> +# define TRY_EMPTY_VM_SPACE0x10
> #else
> # define TRY_EMPTY_VM_SPACE0
> #endif
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Multiarch tuple will be coded in file or directory names in
multiarch-aware distros, so one ABI should have only one multiarch
tuple. For example, "--target=loongarch64-linux-gnu --with-abi=lp64s"
and "--target=loongarch64-linux-gnusf" should both set multiarch tuple
to "loongarch64-linux-gnusf".
On Mon, 2023-02-06 at 21:07 +0800, Lulu Cheng wrote:
>
> 在 2023/2/4 上午1:50, Xi Ruoyao 写道:
> > We can use bytepick.[wd] for
> >
> > a << (8 * x) | b >> (8 * (sizeof(a) - x))
> >
> > while a and b are uint32_t or uint64_t. This is u
We can use bytepick.[wd] for
a << (8 * x) | b >> (8 * (sizeof(a) - x))
while a and b are uint32_t or uint64_t. This is useful for some cases,
for example:
https://sourceware.org/pipermail/libc-alpha/2023-February/145203.html
Bootstrapped and regtested on loongarch64-linux-gnu.
Ok for trunk
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
So I'd consider the issue a GNU ld regression if it suddenly stops to
behave like this.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Fri, 2023-01-27 at 12:50 +0100, Jakub Jelinek wrote:
> On Fri, Jan 27, 2023 at 07:46:27PM +0800, Xi Ruoyao wrote:
> > They prevent the compiler from deeming the NaN result "unused" and
> > remove the calculation raising INVALID exception. See the discussion
&g
They prevent the compiler from deeming the NaN result "unused" and
remove the calculation raising INVALID exception. See the discussion
in PR107608 for details.
Tested on x86_64-linux-gnu where the change fixes the test failure.
Ok for trunk?
gcc/testsuite/ChangeLog:
* gcc.dg/pr95115.c (
s well.
I'd vote a +1, I've applied them to a GCC 12.2 build and used it to
build many packages with -flto=auto. GCC seems communicating with make-
4.4 correctly with these patches.
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be in
loongarch/loongarch-driver.cc
> delete mode 100644 gcc/config/loongarch/loongarch-driver.h
>
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
eview
the change more easily.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
verflow exception and provide "some value" as the output. Then ffint
can't produce the correct result.
Nacked-by: Xi Ruoyao
I'd suggest to add frint.{w,l}.{s,d}.{rm,rp,rz} etc. (BTW, also the
variants without raising inexact exceptions) into a future LoongArch ISA
version for this.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
stealth changes.
Try to break the patch into a series of multiple small patches because
it's difficult to review a very large diff.
Do not randomly modify coding style. Even if you have a good reason to
make style changes, you should submit them as a separate patch (or
separate patch series) because mixing style changes and real code
changes makes it difficult to review the code.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
intenance burden, you can't just
reintroduce the burden and say "hey, I don't want to pay for the burden
so you please do it".
And we are in stage 3 now so it's not possible to merge 50+ patches
(completely not reviewed in stage 1) until GCC 14 stage 1 opens.
--
Xi Ruoyao
On Wed, 2022-11-23 at 17:14 +0800, chenglulu wrote:
>
> 在 2022/11/23 16:59, Xi Ruoyao 写道:
> > On Wed, 2022-11-23 at 14:49 +0800, Lulu Cheng wrote:
> > > 'A' Print a _DB suffix if the memory model requires a
> > > release.
> > > 'b&
ay it to GCC 14: we never
claimed we supported 'c' and it has not worked since the day one we
merged LoongArch port. Is there any emergency reason to support 'c' in
GCC 13?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Tue, 2022-11-22 at 22:03 +0800, Xi Ruoyao via Gcc-patches wrote:
> While I still can't fully understand the immediate load issue and how
> this patch fix it, I've tested this patch (alongside the prefetch
> instruction patch) with bootstrap-ubsan. And the compiled result of
(set_attr "mode" "HI")])
>
> diff --git a/gcc/config/loongarch/predicates.md
> b/gcc/config/loongarch/predicates.md
> index 8bd0c1376c9..58c3dc2261c 100644
> --- a/gcc/config/loongarch/predicates.md
> +++ b/gcc/config/loongarch/predicates.md
> @@ -226,7 +226,7 @@ (define_predicate "move_operand"
> switch (GET_CODE (op))
> {
> case CONST_INT:
> - return !splittable_const_int_operand (op, mode);
> + return true;
>
> case CONST:
> case SYMBOL_REF:
> diff --git a/gcc/testsuite/gcc.target/loongarch/imm-load.c
> b/gcc/testsuite/gcc.target/loongarch/imm-load.c
> new file mode 100644
> index 000..c04ca33996f
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/loongarch/imm-load.c
> @@ -0,0 +1,10 @@
> +/* { dg-do compile } */
> +/* { dg-options "-mabi=lp64d -O2 -fdump-rtl-split1" } */
> +
> +long int
> +test (void)
> +{
> + return 0x1234567890abcdef;
> +}
> +/* { dg-final { scan-rtl-dump-times "scanning new insn with uid" 6
> "split1" } } */
> +
> diff --git a/gcc/testsuite/gcc.target/loongarch/imm-load1.c
> b/gcc/testsuite/gcc.target/loongarch/imm-load1.c
> new file mode 100644
> index 000..2ff02971239
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/loongarch/imm-load1.c
> @@ -0,0 +1,26 @@
> +/* { dg-do compile } */
> +/* { dg-options "-mabi=lp64d -O2" } */
> +/* { dg-final { scan-assembler
> "test:.*lu52i\.d.*\n\taddi\.w.*\n\.L2:" } } */
> +
> +
> +extern long long b[10];
> +static inline long long
> +repeat_bytes (void)
> +{
> + long long r = 0x0101010101010101;
> +
> + return r;
> +}
> +
> +static inline long long
> +highbit_mask (long long m)
> +{
> + return m & repeat_bytes ();
> +}
> +
> +void test(long long *a)
> +{
> + for (int i = 0; i < 10; i++)
> + b[i] = highbit_mask (a[i]);
> +
> +}
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
lib)
> error ("%qs cannot be used for compiling a shared library",
> "-mdirect-extern-access");
> diff --git a/gcc/config/loongarch/loongarch.md
> b/gcc/config/loongarch/loongarch.md
> index 682ab961741..2fda5381904 100644
> --- a/gcc/config/loongarch/loongarch.md
> +++ b/gcc/config/loongarch/loongarch.md
> @@ -3282,6 +3282,20 @@ (define_expand "untyped_call"
> ;;
> ;;
>
> +(define_insn "prefetch"
> + [(prefetch (match_operand 0 "address_operand" "ZD")
> + (match_operand 1 "const_int_operand" "n")
> + (match_operand 2 "const_int_operand" "n"))]
> + ""
> +{
> + switch (INTVAL (operands[1]))
> + {
> + case 0: return "preld\t0,%a0";
> + case 1: return "preld\t8,%a0";
> + default: gcc_unreachable ();
> + }
> +})
> +
> (define_insn "nop"
> [(const_int 0)]
> ""
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
e patch a little (in attachment): rewritten the
ChangeLog and test, and renamed "value_exchange_and" to just
"value_exchange" because we are not doing anything beyond the exchange.
If it looks OK you can just send it as v2.
--
Xi Ruoyao
School of Aeros
On Thu, 2022-11-17 at 10:55 +0800, Jinyang He wrote:
> On 2022/11/17 上午9:39, Jinyang He wrote:
>
> > On 2022/11/16 下午7:46, Xi Ruoyao wrote:
> >
> > > On Wed, 2022-11-16 at 10:11 +0800, Jinyang He wrote:
> > >
> > > > > >
uot;)))
> This setting must be a memory operand.
> ''ZD" constraint is a address operand.
> I think (mem:mode (address operand)) = memory operand.
Yes they are different. I tried reusing "m" in my previous attempt to
add prefetch instruction but it didn't work.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
uArch, for GS464V based core, barrier is required as the
uArch design allows regular load to be reordered after an atomic
linked load, and that would break assumption of compiler atomic
constraints.
Without these dbar instructions I'd got random test failures in GCC
libgomp test suite.
We us
27;d suggest to create a bug report at https://gcc.gnu.org/bugzilla and
post this test in the PR. Then add the PR number into the changelog,
and just add a { dg-do compile } and { dg-final { scan-assembler ... } }
test into the testsuite to ensure the correct ll/sc loop is generated.
A bug repor
On Sat, 2022-11-12 at 17:45 +0800, Xi Ruoyao via Gcc-patches wrote:
> void prefetch(char *ptr, int off)
> {
> return __builtin_prefetch(ptr + off);
> }
>
> It's compiled to "preldx 0,$r4,$r5". I don't think it's correct
> because
> acc
113 + 29
> P4 253 + 6
> P5 25
> --- ---
> Total P1-P3 619 + 29
> Total 897 + 35
>
>
> Previous Report
> ===
>
> https://gcc.gnu.org/pipermail/gcc/2022-October/239690.html
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
han using some -march=whatever.
>
> Sure, can change the check so that it checks for AMD too for now and
> therefore discard the sync.md patch, the question is whom do we talk at
> Zhaoxin and VIA and if there are any further other CX16+AVX CPUs
>
> Jakub
>
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
w if they make the guarantee about atomicity of 16B aligned
access.
>
> OK with the above addition.
>
> Thanks,
> Uros.
>
> > - }
> > -#endif
> > /* See the load in load_feat1. */
> > __atomic_store_n (&__libat_feat1, FEAT1_REGISTER,
> > __ATOMIC_RELAXED);
> > return FEAT1_REGISTER;
> >
> > Jakub
> >
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
refetch(char *ptr, int off)
{
return __builtin_prefetch(ptr + off);
}
It's compiled to "preldx 0,$r4,$r5". I don't think it's correct because
according to the doc, rk should contains several bit-fields instead of
an offset.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Wed, 2022-11-09 at 21:53 +0800, Xi Ruoyao wrote:
> These patches allow to expand the following builtins to floating point
> instructions for LoongArch:
>
> - __builtin_rint{,f}
> - __builtin_{l,ll}rint{,f}
> - __builtin_{l,ll}floor{,f}
> - __builtin_{l,ll}ceil{,f}
> -
On Sat, 2022-11-12 at 11:54 +0800, Lulu Cheng wrote:
>
> 在 2022/11/9 下午9:53, Xi Ruoyao 写道:
> > This allows optimizing __builtin_ldexp{,f} and __builtin_scalbn{,f}
> > with
> > -fno-math-errno.
> >
> > IMODE is added because we can't hard code SI for
implied by -
ffast-math), we don't care about whether exceptions are raised or not.
So lceil and lfloor can be used if -ffp-int-builtin-inexact, or -fno-
trapping-math.
On Fri, 2022-11-11 at 00:07 +0000, Joseph Myers wrote:
> On Thu, 10 Nov 2022, Xi Ruoyao via Gcc-patches wrote:
>
On Thu, 2022-11-10 at 14:41 +0800, Lulu Cheng wrote:
>
> 在 2022/11/9 下午9:53, Xi Ruoyao 写道:
> > +;; Convert floating-point numbers to integers
> > +(define_insn "2"
> > + [(set (match_operand:ANYFI 0 "register_operand" "=f")
> > +
On Wed, 2022-11-09 at 21:49 +0800, Xi Ruoyao wrote:
> Hi Aldy,
>
> This commit breaks the attached test case at -O2 on x86_64-linux-gnu and
^^^
Ah, not this one. I meant r13-3842 "Implement op[12]_range operators
for PLUS_EXPR and MINUS_EXPR."
> loongarch64-
On LoongArch, flogb instructions extract the exponent of a non-negative
floating point value, but produces NaN for negative values. So we need
to add a fabs instruction when we expand logb.
gcc/ChangeLog:
* config/loongarch/loongarch.md (UNSPEC_FLOGB): New unspec.
(type): Add flo
This allows to optimize the following builtins if -fno-math-errno:
- __builtin_lrint{,f}
- __builtin_lfloor{,f}
- __builtin_lceil{,f}
Inspired by
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605287.html.
ANYFI is added so the compiler won't try ftint.l.s if -mfpu=32. If we
simply use
501 - 600 of 984 matches
Mail list logo
