original
> Loongson ISA didn't have revb.d/revb.2w when the GCC port was done and
> it was added afterwards and GCC port was never updated to use the new
> instructions.
revb.2w and revb.d are available since day one. I've no idea why they
weren't used. (Also strangely there's no revb.w, so on t
+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)
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) failu
ction 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
uess-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
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
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 Ch
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 wro
$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. Implementa
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:
> &
On Sat, 2024-07-06 at 10:24 +0800, Xi Ruoyao wrote:
> On Sat, 2024-07-06 at 00:02 +0200, Alejandro Colomar wrote:
> > That's precisely the case with strtol(3): it doesn't access any objects
> > through *endptr, and so that pointer need not be restrict.
> >
> > Then,
s
> accessed or not.
Restrict allows to reorder any writes to other objects with an read from
nptr then. In strtol at least errno can be written, and depending on the
implementation of locale things there may be more.
TBAA does not help here because char aliases with anything.
--
Xi Ruoyao
School of Ae
On Sat, 2024-07-06 at 00:01 +0800, Xi Ruoyao wrote:
> On Fri, 2024-07-05 at 17:53 +0200, Alejandro Colomar wrote:
> > At least, I hope there's consensus that while current GCC doesn't warn
> > about this, ideally it should, which means it should warn for valid uses
> > of s
X, and glibc.
It **shouldn't**. strtol will only violate restrict if it's wrongly
implemented, or something dumb is done like "strtol((const char*) ,
, 0)".
See my previous reply.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
es with argument 1 [-Wrestrict]
6 | strtol((char *), , 10);
|~~ ^~
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
t's ignore error handling for
> b = strtol(p, , 0); // simplicity.
Why this is wrong?
During the execution of strtol() the only expression accessing the
object "p" is *endptr. When the body of strtol() refers "nptr" it
accesses a different object, not "p".
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_64-li
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
= 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.postr
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.
/* snip */
--
https://gcc.gnu.org/g:2280e88ab05ebab994b7db588d577b29f1b12b87
commit r15-1675-g2280e88ab05ebab994b7db588d577b29f1b12b87
Author: Xi Ruoyao
Date: Sun Jun 16 12:22:40 2024 +0800
LoongArch: NFC: Dedup and sort the comment in loongarch_print_operand_reloc
gcc/ChangeLog
https://gcc.gnu.org/g:94aade062a4ab689abc4c3422c1b901ab0733c19
commit r15-1674-g94aade062a4ab689abc4c3422c1b901ab0733c19
Author: Xi Ruoyao
Date: Sat Jun 15 18:29:43 2024 +0800
LoongArch: Tweak IOR rtx_cost for bstrins
Consider
c &= 0xfff;
a &
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/loongarch.md
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
gcc/ChangeLog:
* doc/rtl.texi (jump_table_data): Fix typos.
---
Pushed as obvious.
gcc/doc/rtl.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/doc/rtl.texi b/gcc/doc/rtl.texi
index c1717ab5f6b..a1ede418c21 100644
--- a/gcc/doc/rtl.texi
+++
https://gcc.gnu.org/g:d27049a38a4c07fa1e662ffd66df3f15d330503f
commit r15-1611-gd27049a38a4c07fa1e662ffd66df3f15d330503f
Author: Xi Ruoyao
Date: Tue Jun 25 21:42:38 2024 +0800
doc: gccint: Fix typos in jump_table_data description
gcc/ChangeLog:
* doc/rtl.texi
Ping^4 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_64-li
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_print_operand_reloc):
Dedup and sort the comment describing modifiers.
---
It's a non-functional change thus I've not tested it. Ok for trunk?
gcc/config/loongarch/loongarch.cc | 10 +-
1 file changed, 1
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_rtx_costs or the compiler will not propagate "c & 0xfff"
forward.
gcc/ChangeLog:
* config/loongarch/loongarch.cc:
On Sat, 2024-06-15 at 21:44 +0800, Xi Ruoyao wrote:
> + for (int i = 0; i < 2; i++)
> + *total += set_src_cost (XEXP (op0, i), mode,
> speed);
Oops this is wrong. I need to fix this and regtest again.
--
Xi Ruoyao
School of Aerospace Science an
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/loongarch.md (define_peephole2): Require
optimize_insn_for_size_p () for move/move/bstrins =>
srai/bstrins transform.
---
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_rtx_costs or the compiler will not propagate "c & 0xfff"
forward.
gcc/ChangeLog:
* config/loongarch/loongarch.cc:
I know riscv doesn't implement any of the legacy optabs. But less
> maintained vector targets might need adjustments.
No new test failures on LoongArch.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
;< 31) - 1 + (((off_t) 1 << 31) <<
> 31))
> int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
> && LARGE_OFF_T % 2147483647 == 1)
> ? 1 : -1];
This shouldn't happen. Please regenerate using *vanilla* autoconf-2.69.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
https://gcc.gnu.org/g:d0da347a1dd6e57cb0e0c55fd654d81dde545cf8
commit r15-1207-gd0da347a1dd6e57cb0e0c55fd654d81dde545cf8
Author: Xi Ruoyao
Date: Sun Jun 9 14:43:48 2024 +0800
LoongArch: Use bstrins for "value & (-1u << const)"
A move/bstrins pair is as fast
https://gcc.gnu.org/g:53c703888eb51314f762c8998dc9215871b12722
commit r15-1206-g53c703888eb51314f762c8998dc9215871b12722
Author: Xi Ruoyao
Date: Wed Jun 12 11:01:53 2024 +0800
LoongArch: Fix mode size comparision in loongarch_expand_conditional_move
We were comparing a mode size
es, and your commit has
removed the spaces. But those spaces are completely missing in the
patch sent to gcc-patches. Maybe your mail client has eaten them?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
We were comparing a mode size with word_mode, but word_mode is an enum
value thus this does not really make any sense. (Un)luckily E_DImode
happens to be 8 so this seemed to work, but let's make it correct so it
won't blow up when we add LA32 support or add another machine mode...
gcc/ChangeLog:
On Sat, 2024-05-11 at 17:16 +0200, FX Coudert wrote:
> * libgccjit.h: Include
Per the C standard size_t should be provided by stddef.h.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Ping https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650763.html
again, adding more reviewers into CC...
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 fi
A move/bstrins pair is as fast as a (addi.w|lu12i.w|lu32i.d|lu52i.d)/and
pair, and twice fast as a srli/slli pair. When the src reg and the dst
reg happens to be the same, the move instruction can be optimized away.
gcc/ChangeLog:
* config/loongarch/predicates.md (high_bitmask_operand):
---
Pushed as obvious.
htdocs/gcc-14/changes.html | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 6447898e..7a5eb449 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -1218,9 +1218,9
---
commit b70633d48603da6175aaa1ba0157bd451d7c0c18
Author: Xi Ruoyao
Date: Wed Jun 5 13:11:37 2024 +0800
gcc-14/changes: Fix mislocated in RISC-V changes
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 6447898e..7a5eb449 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/ch
Ping again.
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_64-linux-gnu. Ok for trunk and releases/gcc-14?
>
> Xi Ru
https://gcc.gnu.org/g:e78980fdd5e82e09e26f524e98ad9cd90a29c1c4
commit r14-10249-ge78980fdd5e82e09e26f524e98ad9cd90a29c1c4
Author: Xi Ruoyao
Date: Wed May 22 09:29:43 2024 +0800
LoongArch: Guard REGNO with REG_P in loongarch_expand_conditional_move
[PR115169]
gcc/ChangeLog
https://gcc.gnu.org/g:ded91d857772c0183cc342cdc54d9128f6c57fa2
commit r15-856-gded91d857772c0183cc342cdc54d9128f6c57fa2
Author: Xi Ruoyao
Date: Wed May 22 09:29:43 2024 +0800
LoongArch: Guard REGNO with REG_P in loongarch_expand_conditional_move
[PR115169]
gcc/ChangeLog
gcc/ChangeLog:
PR target/115169
* config/loongarch/loongarch.cc
(loongarch_expand_conditional_move): Guard REGNO with REG_P.
---
Bootstrapped with --enable-checking=all. Ok for trunk and 14?
gcc/config/loongarch/loongarch.cc | 17 -
1 file changed, 12
t "[PATCH v2 1/3] RISC-V: movmem for RISCV with V extension"
>
> This reverts commit df15eb15b5f820321c81efc75f0af13ff8c0dd5b.
Revert is OK, but revert revert is not.
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651144.html
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Ping.
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_64-linux-gnu. Ok for trunk and releases/gcc-14?
>
> Xi Ru
On Thu, 2024-05-09 at 20:21 +, Joseph Myers wrote:
> On Wed, 8 May 2024, Xi Ruoyao wrote:
>
> > In GCC 14 we started to emit URLs for "command-line option is
> > valid for but not " and "-Werror= argument
> > '-Werror=' is not valid for " warnings
https://gcc.gnu.org/g:21051de4bed3d541804bf965cbdc3e8047698777
commit r14-10192-g21051de4bed3d541804bf965cbdc3e8047698777
Author: Xi Ruoyao
Date: Wed May 8 11:25:57 2024 +0800
driver: Move -fdiagnostics-urls= early like -fdiagnostics-color= [PR114980]
In GCC 14 we started to emit
https://gcc.gnu.org/g:f75806ec63ec1af2d76a194e5fa73e114b2b8857
commit r15-355-gf75806ec63ec1af2d76a194e5fa73e114b2b8857
Author: Xi Ruoyao
Date: Wed May 8 11:25:57 2024 +0800
driver: Move -fdiagnostics-urls= early like -fdiagnostics-color= [PR114980]
In GCC 14 we started to emit
In GCC 14 we started to emit URLs for "command-line option is
valid for but not " and "-Werror= argument
'-Werror=' is not valid for " warnings. So we should
have moved -fdiagnostics-urls= early like -fdiagnostics-color=, or
-fdiagnostics-urls= wouldn't be able to control URLs in these
On Tue, 2024-05-07 at 18:01 +0800, Lulu Cheng wrote:
>
> 在 2024/5/7 下午5:42, Xi Ruoyao 写道:
> > On Tue, 2024-05-07 at 17:07 +0800, Xi Ruoyao wrote:
> > > Hmm, after this change the default (-march=la64v1.0) is enabling LSX:
> > >
> > > $ e
On Tue, 2024-05-07 at 17:07 +0800, Xi Ruoyao wrote:
> Hmm, after this change the default (-march=la64v1.0) is enabling LSX:
>
> $ echo "int dummy;" | cc -c -v |& tail -n1
> COLLECT_GCC_OPTIONS='-c' '-v' '-mabi=lp64d' '-march=la64v1.0' '-
> mfpu=64'
> '-msimd=lsx' '
LOONGARCH64:
> > + case TUNE_LA464:
> > + case TUNE_LA664:
> > /* Vector part. */
> > if (LSX_SUPPORTED_MODE_P (mode) || LASX_SUPPORTED_MODE_P
> > (mode))
> > {
> > @@ -10980,9
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_64-linux-gnu. Ok for trunk and releases/gcc-14?
Xi Ruoyao (2):
i386: testsuite: Add -no-pie for pr113689-1.c [PR70150]
i386: testsuite: Adapt
After r14-811 "call *nop@GOTPCREL(%rip)" is only generated with
-mno-direct-extern-access even if --enable-default-pie. So the r13-1614
change to this file is not valid anymore.
gcc/testsuite/ChangeLog:
PR testsuite/70150
* gcc.target/i386/fentryname3.c (dg-final): Revert
For a --enable-default-pie build, using -fno-pic (for compiler) but
not -no-pie (for linker) triggers some linker warnings counted as
excess errors:
/usr/bin/ld: /tmp/cc8MgxiR.o: warning: relocation in read-only
section `.text.startup'
/usr/bin/ld: warning: creating DT_TEXTREL in a
On Sat, 2024-04-27 at 11:04 +0800, Lulu Cheng wrote:
> LGTM!
>
> Thanks.
Pushed r15-11 and r14-10142.
> 在 2024/4/26 下午9:52, Xi Ruoyao 写道:
> > Without the constrants, the compiler attempts to use a stack slot as the
> > target, causing an ICE building the kernel with -O
https://gcc.gnu.org/g:3e04b6f6ba568e6183e8aa8223d4156234503843
commit r14-10142-g3e04b6f6ba568e6183e8aa8223d4156234503843
Author: Xi Ruoyao
Date: Fri Apr 26 15:59:11 2024 +0800
LoongArch: Add constraints for bit string operation define_insn_and_split's
[PR114861]
Without
https://gcc.gnu.org/g:140124ad54eef88ca87909f63aedc8aaeacefc65
commit r15-11-g140124ad54eef88ca87909f63aedc8aaeacefc65
Author: Xi Ruoyao
Date: Fri Apr 26 15:59:11 2024 +0800
LoongArch: Add constraints for bit string operation define_insn_and_split's
[PR114861]
Without
Without the constrants, the compiler attempts to use a stack slot as the
target, causing an ICE building the kernel with -Os:
drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:3144:1:
error: could not split insn
(insn:TI 1764 67 1745
(set (mem/c:DI (reg/f:DI 3 $r3) [707 %sfp+-80 S8 A64])
does not support HPTW, which
**is** a v1.1 feature.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
uot;+Generate instructions for the machine type
> @var{arch-type}.",
>
> so is there no need to write it like this here?
Then maybe just say "all LoongArch v1.1 instructions" instead of
"features" here as well?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
A version 1.1.
IMO it's better to use a wording like LA664, i.e. "a CPU implementing
all LoongArch v1.1 unprivileged features" (emphasising "all", as the
v1.1 manual allows to only implement a subset of v1.1 features).
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
ventions, which
> the LoongArch GCC port aims to conform to.
The links seems broken. Do you mean la-softdev-convention?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
I do LTO,
so I don't really rely on this patch though.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
this line.
> (loongarch_expand_builtin): Turn assertion of builtin
> availability
> into a test.
and this line.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
.length ();
> + if (l != p2.m_padding.length ())
> + return false;
> + for (unsigned i = 0; i < l; i++)
> + if (p1.m_padding[i].first != p2.m_padding[i].first
> + || p1.m_padding[i].second != p2.m_padding[i].second)
> + return false;
> +
> + return true;
> +}
&
farm. If that goes well, I intend to commit the patch and then start
> working on backports.
I've tried these two patches out on my own 24-core AArch64 machine.
Bootstrapped (but no LTO or PGO) and regtested fine.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Sun, 2024-04-07 at 16:23 +0800, Yang Yujie wrote:
> On Sun, Apr 07, 2024 at 04:23:53PM +0800, Xi Ruoyao wrote:
> > On Sun, 2024-04-07 at 15:47 +0800, Yang Yujie wrote:
> > > This patch fixes the back-end context switching in cases where functions
> > > should be
R target/113233
Oops, so this PR isn't fixed with r14-7134 "LoongArch: Implement option
save/restore"? Should I reopen it?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
invoke.texi for
> the
^ ^
Better have two commas here.
Otherwise it should be OK.
> + format. */
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
cc.target/loongarch/explicit-relocs-auto-tls-desc.c: New test.
> * gcc.target/loongarch/explicit-relocs-extreme-tls-desc.c: New test.
> * gcc.target/loongarch/explicit-relocs-tls-desc.c: New test.
>
> Co-authored-by: Lulu Cheng
> Co-authored-by: Xi Ruoyao
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Mon, 2024-04-01 at 10:22 +0800, chenglulu wrote:
>
> 在 2024/4/1 上午9:29, Xi Ruoyao 写道:
> > On Fri, 2024-03-29 at 09:23 +0800, chenglulu wrote:
> >
> > > I tested spec2006. In the floating-point program, the test items with
> > > large
> > >
some workloads like competitive programming. However "adapting with
different modulos" is not possible w/o refactoring generic code so it
must be deferred to at least GCC 15.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
https://gcc.gnu.org/g:1ab646f678a9d47b338424ed69e9ae5d774b06ae
commit r13-8527-g1ab646f678a9d47b338424ed69e9ae5d774b06ae
Author: Xi Ruoyao
Date: Wed Mar 20 15:09:21 2024 +0800
mips: Fix C23 (...) functions returning large aggregates [PR114175]
We were assuming
https://gcc.gnu.org/g:b73a6a20113ca607cf3073c751698b12aa167881
commit r13-8526-gb73a6a20113ca607cf3073c751698b12aa167881
Author: Xi Ruoyao
Date: Mon Mar 18 17:18:34 2024 +0800
LoongArch: Fix C23 (...) functions returning large aggregates [PR114175]
We were assuming
https://gcc.gnu.org/g:6fc84f680d098f82c1c43435fdb206099f0df4df
commit r14-9728-g6fc84f680d098f82c1c43435fdb206099f0df4df
Author: Xi Ruoyao
Date: Wed Mar 20 15:09:21 2024 +0800
mips: Fix C23 (...) functions returning large aggregates [PR114175]
We were assuming
https://gcc.gnu.org/g:26a723625bb63e42b8c78bbce52ba0286eefda1c
commit r14-9717-g26a723625bb63e42b8c78bbce52ba0286eefda1c
Author: Xi Ruoyao
Date: Tue Feb 6 17:49:50 2024 +0800
testsuite: Add a test case for negating FP vectors containing zeros
Recently I've fixed two wrong FP
Ping.
On Wed, 2024-03-20 at 15:10 +0800, Xi Ruoyao wrote:
> We were assuming TYPE_NO_NAMED_ARGS_STDARG_P don't have any named
> arguments and there is nothing to advance, but that is not the case
> for (...) functions returning by hidden reference which have one such
> artific
On Wed, 2024-03-27 at 18:39 +0800, Xi Ruoyao wrote:
> On Wed, 2024-03-27 at 10:38 +0800, chenglulu wrote:
> >
> > 在 2024/3/26 下午5:48, Xi Ruoyao 写道:
> > > The latency of LA464 and LA664 division instructions depends on the
> > > input. When I updated the costs i
On Wed, 2024-03-27 at 08:54 +0100, Richard Biener wrote:
> On Tue, Mar 26, 2024 at 10:52 AM Xi Ruoyao wrote:
> >
> > The latency of LA464 and LA664 division instructions depends on the
> > input. When I updated the costs in r14-6642, I unintentionally set the
> > divi
On Wed, 2024-03-27 at 10:38 +0800, chenglulu wrote:
>
> 在 2024/3/26 下午5:48, Xi Ruoyao 写道:
> > The latency of LA464 and LA664 division instructions depends on the
> > input. When I updated the costs in r14-6642, I unintentionally set the
> > division costs to the best-case
On Tue, 2024-03-26 at 11:15 +0800, YunQiang Su wrote:
/* snip */
> With -ffinite-math-only -fno-signed-zeros, it does work with
> x >= y ? x : y
> while without `-ffinite-math-only -fno-signed-zeros`, it cannot.
> @Xi Ruoyao Is it expected by IEEE?
When y is (quiet) NaN and x
1 - 100 of 1006 matches
Mail list logo
