).
If int64_t etc. were defined as builtin types since epoch, things would
be a lot easier. But we can't change history.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Thu, 2022-08-25 at 09:48 +0200, Alejandro Colomar wrote:
> Hi Xi,
>
> On 8/25/22 09:28, Xi Ruoyao wrote:
> > On Thu, 2022-08-25 at 09:20 +0200, Alejandro Colomar via Gcc-patches
> > wrote:
> > > I don't know for sure, and I never pretended to say otherwi
ed in 1/2 before committing.
> Others I think are ok.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Thu, 2022-08-25 at 16:29 +0800, Lulu Cheng wrote:
>
> 在 2022/8/24 下午10:03, Xi Ruoyao 写道:
>
> > SYMBOL_REF_TLS_MODEL invokes SYMBOL_REF_FLAGS, and SYMBOL_REF_FLAGS
> > invokes RTL_FLAG_CHECK1 and aborts when RTL code is not SYMBOL_REF.
> >
> > r13-1833 rem
On Thu, 2022-08-25 at 17:12 +0800, Xi Ruoyao via Gcc-patches wrote:
> On Thu, 2022-08-25 at 16:53 +0800, Lulu Cheng wrote:
> > I think this should add a sentence:
> >
> >
> > "Currently, the identifier name can only be one of small or
> > extreme."
On Fri, 2022-08-26 at 22:20 +, Eugene Rozenfeld wrote:
> The patch is approved.
Thanks, pushed r13-2234.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Sat, 2022-07-09 at 10:11 -0600, Jeff Law via Gcc-patches wrote:
> Once Alex is OK with this patch, then it'll be good to go.
>
> jeff
Gentle ping as a distro maintainer :).
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
The LoongArch support for libubsan and libasan has been added in:
- https://reviews.llvm.org/D129371
- https://reviews.llvm.org/D129418
and we've merged them in r13-2269. It's time to enable them.
No unexpected failures in GCC asan.exp and ubsan.exp tests.
libsanitizer/ChangeLog:
* co
We'd like to introduce a new codegen option to align with the old
"-Wa,-mla-global-with-pcrel" and avoid a performance & size regression
building the Linux kernel with new-reloc toolchain. And it should be
also useful for building statically linked executables, firmwares (EDK2
for example), and ot
On Fri, 2022-09-02 at 11:12 +0800, Huacai Chen wrote:
> On Thu, Sep 1, 2022 at 6:56 PM Xi Ruoyao wrote:
> >
> > We'd like to introduce a new codegen option to align with the old
> > "-Wa,-mla-global-with-pcrel" and avoid a performance & size
> > reg
On Thu, 2022-09-01 at 18:54 +0800, Xi Ruoyao wrote:
> We'd like to introduce a new codegen option to align with the old
> "-Wa,-mla-global-with-pcrel" and avoid a performance & size regression
> building the Linux kernel with new-reloc toolchain. And it should b
%plt from "new"
assembly code, i. e. stop to print %plt(...) in GCC completely?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Sun, 2022-09-04 at 11:22 +0800, Lulu Cheng wrote:
>
> 在 2022/9/4 上午10:51, Xi Ruoyao 写道:
>
> > On Sun, 2022-09-04 at 10:26 +0800, Lulu Cheng wrote:
> >
> > > If the above modifications are not added, the function call is:
> > >
> > > bl %p
v1 -> v2:
Move TARGET_DIRECT_EXTERN_ACCESS check from loongarch_classify_symbol to
loongarch_symbol_binds_local_p, so "%plt" is not output if
-mdirect-extern-access used.
-- >8 --
As a new target, LoongArch does not use copy relocation as it's
problematic in some circumstances. One bad conseque
I think.
But let's defer the "controversial" thing and eliminate the GOT in
upcoming Linux-6.1 first...
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
HI32_OPERAND): New macro.
> * config/loongarch/loongarch.md (load_hi32): New template.
> * config/loongarch/predicates.md (const_hi32_operand): Determines
> whether the value is an immediate number that has a value of only
> the higher 32 bits.
>
On Fri, 2022-11-04 at 10:33 +0800, Lulu Cheng wrote:
>
> 在 2022/11/4 上午10:22, Xi Ruoyao 写道:
> > On Tue, 2022-11-01 at 20:04 +0800, Lulu Cheng wrote:
> > > gcc/ChangeLog:
> > >
> > > * config/loongarch/constraints.md (x): New constraint.
> &g
On Fri, 2022-10-21 at 22:15 +, Joseph Myers wrote:
> * config/loongarch/loongarch.cc
> (loongarch_setup_incoming_varargs): Likewise.
Hi,
One test fails on loongarch64-linux-gnu:
FAIL: gcc.dg/c2x-stdarg-4.c execution test
I've not got time to debug the issue y
On Fri, 2022-11-04 at 13:29 +0800, Xi Ruoyao via Gcc-patches wrote:
> On Fri, 2022-10-21 at 22:15 +, Joseph Myers wrote:
>
> > * config/loongarch/loongarch.cc
> > (loongarch_setup_incoming_varargs): Likewise.
>
> Hi,
>
> One test fails on lo
Signed overflow is an undefined behavior, so we need to prevent it from
happening, instead of "checking" the result.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_emit_int_compare):
Avoid signed overflow.
---
Bootstrapped and regtested on loongarch64-linux-gnu. OK fo
Add fcopysign.{s,d} with the names copysign{sf,df}3 so GCC will expand
__builtin_copysign{f,} to a single instruction.
Link: https://sourceware.org/pipermail/libc-alpha/2022-November/143177.html
gcc/ChangeLog:
* config/loongarch/loongarch.md (UNSPEC_FCOPYSIGN): New unspec.
(type)
On Sun, 2022-11-06 at 09:57 +0800, Lulu Cheng wrote:
>
> 在 2022/11/4 下午10:37, Xi Ruoyao 写道:
> > Add fcopysign.{s,d} with the names copysign{sf,df}3 so GCC will expand
> > __builtin_copysign{f,} to a single instruction.
> >
> > Link: https://sourceware.org/pipe
decrement && rhs == HOST_WIDE_INT_MIN))
> + break;
> +
>
> It is not necessary to continue when *code matches one of
> mag_comparisons[i].
Ah yes, I misread the code :(.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
ning xz -T0 on different machines (with different
core numbers) may produce different compressed data. The difference can
cause trouble distributing checksums.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Wed, 2022-11-09 at 01:52 +, Joseph Myers wrote:
> On Tue, 8 Nov 2022, Xi Ruoyao via Gcc-patches wrote:
>
> > I'm wondering if running xz -T0 on different machines (with different
> > core numbers) may produce different compressed data. The difference can
> &g
-linux-gnu. And a modified
Glibc using the builtins for rint{,f}, {l,ll}rint{,f}, and logb{,f}
also survived Glibc test suite.
Please review ASAP because GCC 13 stage 1 will end on Nov. 13th.
Xi Ruoyao (4):
LoongArch: Rename frint_ to rint2
LoongArch: Add ftint{,rm,rp}.{w,l}.{s,d} instructions
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
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 operand 2: fscaleb.d
instruction always take the high half of both source registers into
account. See my_ldexp_long in the test case.
gcc/ChangeLog:
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
Use standard name so __builtin_rint{,f} can be expanded to one
instruction.
gcc/ChangeLog:
* config/loongarch/loongarch.md (frint_): Rename to ..
(rint2): .. this.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/frint.c: New test.
---
gcc/config/loongarch/loongarch.md
Signed overflow is an undefined behavior, so we need to prevent it from
happening, instead of "checking" the result.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_emit_int_compare):
Avoid signed overflow.
---
v1 -> v2: break instead of continue if the inc/dec will ove
#x27;m wrong :(.
This patch breaks:
long x(double d)
{
return __builtin_ceil(d);
}
The compiler then folds it into __builtin_lceil and produce
ftintrp.l.d $f0,$f0, even if -fno-fp-int-builtin-inexact is used.
I'll revise this patch to limit lceil and lfloor for -ffp-int-builtin-
inexact only.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
gt; + return __builtin_lceil(i);
> +}
> +
> +int
> +floor1(float i)
> +{
> + return __builtin_lfloor(i);
> +}
> +
> +long
> +floor2(float i)
> +{
> + return __builtin_lfloor(i);
> +}
> +
> +long long
> +floor3(float i)
> +{
> + return __builtin_lfloor(i);
> +}
> +
> +int
> +floor4(double i)
> +{
> + return __builtin_lfloor(i);
> +}
> +
> +long
> +floor5(double i)
> +{
> + return __builtin_lfloor(i);
> +}
> +
> +long long
> +floor6(double i)
> +{
> + return __builtin_lfloor(i);
> +}
> +
> +/* { dg-final { scan-assembler-times "fcvt.l.s" 6 } } */
> +/* { dg-final { scan-assembler-times "fcvt.l.d" 6 } } */
> +/* { dg-final { scan-assembler-not "call" } } */
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
us;
> +
> // Instantiate a range_op_table for floating point operations.
> static floating_op_table global_floating_table;
>
> @@ -1917,6 +1940,7 @@ floating_op_table::floating_op_table ()
> set (ABS_EXPR, fop_abs);
> set (NEGATE_EXPR, fop_negate);
> set (PLUS_EXPR,
-linux-gnu. And a modified
Glibc using the builtins for rint{,f}, {l,ll}rint{,f}, and logb{,f}
also survived Glibc test suite.
Please review ASAP because GCC 13 stage 1 will end on Nov. 13th.
v1 -> v2: Only use ftint{rm,rp} instructions if floor and ceil are
allowed to raise inexact exception.
Use standard name so __builtin_rint{,f} can be expanded to one
instruction.
gcc/ChangeLog:
* config/loongarch/loongarch.md (frint_): Rename to ..
(rint2): .. this.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/frint.c: New test.
---
gcc/config/loongarch/loongarch.md
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 operand 2: fscaleb.d
instruction always take the high half of both source registers into
account. See my_ldexp_long in the test case.
gcc/ChangeLog:
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
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
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 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")
> > +
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 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
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}
> -
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
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
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
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
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
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
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
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
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:
> > >
> > > > > >
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
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
ctly, setting VTV_PAGE_SIZE to 4KB will obviously break 16KB or
64KB configuration.)
If VTV_PAGE_SIZE == sysconf (_SC_PAGE_SIZE) is strictly required for
libvtv we'll have to keep the check as-is and then we'll only support
16KB page configuration (which is the default in Linux kernel
.c scan-tree-dump-times dse1 "VEC_PERM_EXPR" 1
on loongarch64-linux-gnu. Not sure why.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
LoongArch always support clz and ctz instructions, so we can always use
__builtin_{clz,ctz} for count_{leading,trailing}_zeros. This improves
the code of libgcc, and also benefits Glibc once we merge longlong.h
there.
Bootstrapped and regtested on loongarch64-linux-gnu.
include/ChangeLog:
4346.c?
I'm not sure if we can add TARGET_VECTORIZE_VEC_PERM_CONST when we don't
actually support vector. (LoongArch has SIMD instructions but the
support in GCC won't be added in a very recent future.)
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Thu, 2022-10-13 at 16:43 +0800, Lulu Cheng wrote:
> Looks good to me!
>
> Thanks!
Pushed r13-3269.
>
> 在 2022/10/12 下午10:23, Xi Ruoyao 写道:
> > LoongArch always support clz and ctz instructions, so we can always
> > use
> > __builtin_{clz,ctz} for coun
On Mon, 2022-10-17 at 15:28 +0200, Martin Liška wrote:
> Hello.
>
> Based on the very positive feedback I was given at the Cauldron Sphinx
> Documentation BoF,
> I'm planning migrating the documentation on 9th November. There are still
> some minor comments
> from Sandra when it comes to the PDF
(CC our team members.)
On Thu, 2022-10-20 at 13:27 +0200, Martin Liška wrote:
> > Ouch. This will be very painful for Linux From Scratch. We'll need to
> > add 23 Python modules to build the documentation, while we only have 88
> > packages in total currently... And we don't want to omit GCC
>
On Thu, 2022-10-20 at 13:53 +0200, Martin Liška wrote:
> On 10/20/22 13:49, Xi Ruoyao wrote:
> > (CC our team members.)
> >
> > On Thu, 2022-10-20 at 13:27 +0200, Martin Liška wrote:
> > > > Ouch. This will be very painful for Linux From Scratch. We'll ne
tainer of Deepin (a distro) has complained that
some packages were depending on libitm (and/or libvtv).
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
]
> +{
> + operands[4] = GEN_INT (INTVAL (operands[3]) << 12 >> 12);
It's an undefined behavior if INTVAL (operands[3]) is negative.
> + operands[5] = GEN_INT (INTVAL (operands[3]) & 0xfff0);
> + operands[6] = GEN_INT (0xf);
> +}
> + [(set_attr "insn_count" "2")])
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
69482-1.c
> @@ -1,5 +1,5 @@
> /* { dg-do compile } */
> -/* { dg-options "-O3" } */
> +/* { dg-options "-O3 -fno-stack-protector" } */
>
> static inline void memset_s(void* s, int n) {
> volatile unsigned char * p = s;
>
> base-commit: 070a6bf0bdc6761ad77ac97404c98f00a7007d54
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Fri, 2023-06-30 at 04:08 +0800, Xi Ruoyao wrote:
> On Thu, 2023-06-29 at 16:01 -0400, Marek Polacek via Gcc-patches wrote:
> > These tests fail when the testsuite is executed with -fstack-
> > protector-strong.
> > To avoid this, this patch adds -fno-stack-pr
+
> gcc/config/loongarch/predicates.md | 333 +-
> 25 files changed, 28723 insertions(+), 290 deletions(-)
> create mode 100644 gcc/config/loongarch/lasx.md
> create mode 100644 gcc/config/loongarch/lasxintrin.h
> create mode 100644 gcc/config/loongarch/lsx.md
> create mode 100644 gcc/config/loongarch/lsxintrin.h
>
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
be LP64D anymore), or we add some special switch for
it (like x86's -msseregparm and sseregparm attribute).
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Fri, 2023-06-30 at 10:16 +0800, Chenghui Pan wrote:
> +(define_c_enum "unspec" [
> + UNSPEC_LSX_ASUB_S
> + UNSPEC_LSX_VABSD_U
> + UNSPEC_LSX_VAVG_S
/* ... */
To me many of them can be modeled using RTL templates, instead of an
unspec.
--
Xi Ruoyao
School of
25 files changed, 28723 insertions(+), 290 deletions(-)
> create mode 100644 gcc/config/loongarch/lasx.md
> create mode 100644 gcc/config/loongarch/lasxintrin.h
> create mode 100644 gcc/config/loongarch/lsx.md
> create mode 100644 gcc/config/loongarch/lsxintrin.h
>
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
If a bit-field is signed and it's wider than the output type, we must
ensure the extracted result sign-extended. But this was not handled
correctly.
For example:
int x : 8;
long y : 55;
bool z : 1;
The vectorized extraction of y was:
vect__ifc__49.29_110 =
MEM [(struct I
to 'load_widen' and 'sign_ext' to 'ref_sext'? As
> they
> are named it suggest they apply to the same so I originally thought sign_ext
> should be widening && !TYPE_UNSIGNED.
I'll rename them.
I'll send a v2 after testing it.
>
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
If a bit-field is signed and it's wider than the output type, we must
ensure the extracted result sign-extended. But this was not handled
correctly.
For example:
int x : 8;
long y : 55;
bool z : 1;
The vectorized extraction of y was:
vect__ifc__49.29_110 =
MEM [(struct I
On Mon, 2023-07-10 at 10:33 +, Richard Biener wrote:
> On Fri, 7 Jul 2023, Xi Ruoyao wrote:
>
> > If a bit-field is signed and it's wider than the output type, we
> > must
> > ensure the extracted result sign-extended. But this was not handled
> &
stsuite/g++.dg/vect/pr110557.cc:12:8: warning: width of
> 'Item::y' exceeds its type
Ah sorry, I didn't consider ports with 32-bit long.
The attached patch should fix the issue. It has been tested and pushed
r14-2427 and r13-7555.
--
Xi Ruoyao
School of Ae
to gcc-patches@gcc.gnu.org for a review, see
https://gcc.gnu.org/contribute.html for the details. Generally we
consider patches attached in bugzilla as drafts.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
/2 reviewed and committed first.
> Also, can I tweak the commit message without being approved again,
> such as attaching the benchmark result?
Yes, as long as the ChangeLog is still correct (the Git hook will reject
a push with wrong ChangeLog format anyway).
--
Xi Ruoyao
School of Aerospace S
d the entire system with these GCC patches and -mlasx in
Aug (after Glibc-2.38 release) as a field test too.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
If the host triple and the target triple are different but the host is
LoongArch, in some cases --with-arch=native can be useful. For example,
if we are bootstrapping a loongarch64-linux-musl toolchain on a
Glibc-based system and we don't intend to use the toolchain on other
machines, we can use
to at least guard it with #ifdef __GNUC__.
And IMO it's just hiding the real problem.
We need more info of the "particular machine". Is this a hardware bug
(i.e. the machine violates the AArch64 spec) or a GCC code generation
issue? Or should we generally use -ffp-contract=off in BOOT
. not compile vs may trigger floating
> point rounding inaccuracies?)
It's possible that the test itself is flaky. Can you provide some
detail about how it fails?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Fri, 2023-07-21 at 16:58 +0300, Alexander Monakov wrote:
>
> On Fri, 21 Jul 2023, Xi Ruoyao via Gcc-patches wrote:
>
> > Perhaps -ffp-contract=on (not off) is enough to fix the issue (if you
> > are building GCC 14 snapshot). The default is "fast" (if no -
h is only used once?
> + tree type,ftype;
> + tree const_string_type
> +
> =build_pointer_type(build_qualified_type(char_type_node,TYPE_QUAL_CONST));
Really bad format. In GNU coding standard you should have a white space
after '=', and before '(', etc. Please fix the formatting everywhere.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
turn 0;
> +}
Same logic error. And this seems exactly same as nanq, the analogous is
definitely wrong because __builtin_nanq should return a quiet NaN, but
__builtin_nansq should return a signaling NaN.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Tue, 2023-08-08 at 10:24 +0800, Xi Ruoyao wrote:
And I think this way to implement these functions (using libgcc calls)
is not the best.
On 64-bit LoongArch a __float128 is stored in a pair of GPR, so
operations like copysignq and absq can be implemented much more
efficiently by expanding
uld be actually used
instead. They are bugs preventing us from implementing -mabi=ilp32d -
march=loongarch64 and they should be fixed. They are not our excuse to
blindly "simulate" what RISC-V has.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
ull/28.
Unfortunately for LP64 ABI _ABILP64 is already a part of public API.
I've tried to raise a deprecation warning for them, but it seems doing
so needs a major change in libcpp... However ILP32 ABI is "fresh new"
so we should take the advantage to remove the historic burden.
GE))
> (set (match_dup 1)
> (match_operand:GPR 2 "register_operand" "r"))]
> - ""
> + "TARGET_64BIT"
> "amswap%A3.\t%0,%z2,%1"
> [(set (attr "length") (const_int 8))])
>
> @@ -182,7 +182,7 @@
> [(match_operand:QI 0 "register_operand" "") ;; bool output
> (match_operand:QI 1 "memory_operand" "+ZB") ;; memory
> (match_operand:SI 2 "const_int_operand" "")] ;; model
> - ""
> + "TARGET_64BIT"
> {
> /* We have no QImode atomics, so use the address LSBs to form a mask,
> then use an aligned SImode atomic. */
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
> +
> +mscatter
> +Target
> +Enable vectorization for scatter instruction.
> +
> mpreferred-stack-boundary=
> Target RejectNegative Joined UInteger
> Var(ix86_preferred_stack_boundary_arg)
> Attempt to keep stack aligned to this power of 2.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
NT) const_op & GET_MODE_MASK (int_mode),
> + GET_RTX_NAME (adjusted_code), n);
> }
> poly_int64 offset = (BYTES_BIG_ENDIAN
> ? 0
> : (GET_MODE_SIZE (int_mode)
> - GET_MODE_SIZE (narrow_mode_iter)));
> *pop0 = adjust_address_nv (op0, narrow_mode_iter, offset);
> - *pop1 = GEN_INT (n);
> + *pop1 = gen_int_mode (n, narrow_mode_iter);
> return adjusted_code;
> }
> }
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
subst $(comma),
> ,$(TM_MULTILIB_CONFIG)),\
> $(call gen_mlib_spec,$(subst /, ,$(mlib
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
configure options --with-simd={none,lsx,lasx};
> new driver options -m[no]-l[a]sx / -msimd={none,lsx,lasx}.
What's the relationship between -mlasx and -msimd=lasx? What will
happen if the user specifies -mlasx -msimd=none or -mlasx -msimd=lsx?
--
Xi Ruoyao
School of Aerospace Scie
RCH", la_target.cpu_arch);
> LARCH_CPP_SET_PROCESSOR ("_LOONGARCH_TUNE", la_target.cpu_tune);
>
> + LARCH_CPP_SET_PROCESSOR ("__loongarch_arch", la_target.cpu_arch);
> + LARCH_CPP_SET_PROCESSOR ("__loongarch_tune", la_target.cpu_tune);
> +
> /* Base architecture / ABI. */
> if (TARGET_64BIT)
> {
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
garch64|la464"
I think we can remove tune_pattern completely. There is no reason to
limit --with-tune setting based on --with-arch setting.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
uration? To me with --
disable-configuration everything should be still in the toplevel
directory, not any sub-directory.
/* snip */
> ChangeLog:
>
> * config-ml.in: add loongarch support. Allow overriding
Use a tab, not 8 white spaces. Likewise for all patches in the series.
>
On Mon, 2023-08-14 at 13:38 +0800, Xi Ruoyao wrote:
>
> > However, for LoongArch, we do not want such a "toplevel" library
> > installation since the default ABI may change. We expect all
> > multilib variants of libraries to be installed to their designated
>
no real reason to make -mlasx and
-msimd=lasx two different things).
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Mon, 2023-08-14 at 13:58 +0800, Xi Ruoyao via Gcc-patches wrote:
> On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie wrote:
> > * Support options for LoongArch SIMD extensions:
> > new configure options --with-simd={none,lsx,lasx};
> > new driver options -m[no]-l[a]sx /
On Mon, 2023-08-14 at 15:37 +0800, Yujie Yang wrote:
> On Mon, Aug 14, 2023 at 01:38:40PM +0800, Xi Ruoyao wrote:
> > On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie wrote:
> >
> > > However, for LoongArch, we do not want such a "toplevel" library
> > > in
601 - 700 of 980 matches
Mail list logo
