On Tue, 2023-04-18 at 21:06 +0800, Lulu Cheng wrote:
> Hi, ruoyao:
>
> Thank you so much for making this submission. But we are testing the
> impact of these two alignment parameters
>
> (also including -falign-jumps and -falign-lables ) on performance. So
> before the result comes out, this pa
We used to skip ifunc check when CX16 is available. But now we use
CX16+AVX+Intel/AMD for the "perfect" 16b load implementation, so CX16
alone is not a sufficient reason not to use ifunc (see PR104688).
This causes a subtle and annoying issue: when GCC is built with a
higher -march= setting in CF
On Sat, 2023-06-03 at 14:53 +0200, Bernhard Reutner-Fischer wrote:
> On 3 June 2023 13:25:32 CEST, Xi Ruoyao via Gcc-patches
> wrote:
>
> > There seems no good way to check if the CPU is Intel or AMD from
> > the built-in macros (maybe we can check every known mod
Ping (in hopes that someone can review before the weekend).
On Sat, 2023-06-03 at 19:25 +0800, Xi Ruoyao wrote:
> We used to skip ifunc check when CX16 is available. But now we use
> CX16+AVX+Intel/AMD for the "perfect" 16b load implementation, so CX16
> alone is not a sufficient reason not to us
On Tue, 2023-05-30 at 09:30 +0800, Lulu Cheng wrote:
>
> 在 2023/5/29 下午2:09, Xi Ruoyao 写道:
> > On Tue, 2023-04-18 at 21:06 +0800, Lulu Cheng wrote:
> > > Hi, ruoyao:
> > >
> > > Thank you so much for making this submission. But we are testing
> > > the
> > > impact of these two alignment paramete
On Tue, 2023-06-13 at 20:23 +0800, Jiufu Guo via Gcc-patches wrote:
> Compare with previous version, this addes ChangeLog and removes
> const_anchor parts.
> https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621356.html.
[Off topic]
const_anchor is just broken now. See
https://gcc.gnu.org/bug
The LA464 micro-architecture is sensitive to alignment of code. The
Loongson team has benchmarked various combinations of function, the
results [1] show that 16-byte label alignment together with 32-byte
function alignment gives best results in terms of SPEC score.
Add a mtune-based table-driven
On Wed, 2023-06-14 at 09:55 +0800, Jiufu Guo wrote:
> Hi,
>
> Xi Ruoyao writes:
>
> > On Tue, 2023-06-13 at 20:23 +0800, Jiufu Guo via Gcc-patches wrote:
> >
> > > Compare with previous version, this addes ChangeLog and removes
> > > const_anchor parts.
> > > https://gcc.gnu.org/pipermail/gcc-p
Pushed r14-1839.
On Thu, 2023-06-15 at 09:12 +0800, Lulu Cheng wrote:
> LGTM! Thanks!
>
> 在 2023/6/14 上午8:43, Xi Ruoyao 写道:
> > The LA464 micro-architecture is sensitive to alignment of code. The
> > Loongson team has benchmarked various combinations of function, the
> > results [1] show that 16
Xuerui: I guess this makes it sensible to show "ret" instead of "jirl
$zero, $ra, 0" in objdump -d output, but I don't know how to implement
it. Do you have some idea?
On Thu, 2023-06-15 at 16:27 +0800, Lulu Cheng wrote:
> Pushed to trunk and gcc-12 gcc-13.
> r14-1866
> r13-7448
> r12-9698
>
> 在
On Wed, 2023-07-12 at 16:58 +0800, Ng YongXiang via Gcc-patches wrote:
> I'm writing to seek for a review for an issue I filed some time ago.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057 . A proposed patch is
> attached in the bug tracker as well.
You should send the patch to gcc-patches@
On Wed, 2023-07-12 at 11:32 -0700, Ken Matsui via Gcc-patches wrote:
> > conditional on the front-end change being committed first of course
>
> Does this mean we want to commit this [2/2] patch before committing
> the [1/2] patch in this case?
No, this mean you should get 1/2 reviewed and commit
On Tue, 2023-07-18 at 19:06 +0800, Chenghui Pan wrote:
> Lulu Cheng (8):
> LoongArch: Added Loongson SX vector directive compilation framework.
> LoongArch: Added Loongson SX base instruction support.
> LoongArch: Added Loongson SX directive builtin function support.
> LoongArch: Added Loon
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
On Fri, 2023-07-21 at 13:11 +0100, Matthew Malcomson via Gcc-patches
wrote:
> This change ensures those operations are not fused and hence stops the test
> being flaky on that particular machine. There is no expected change in the
> generated code.
> Bootstrap & regtest on AArch64 passes with no r
On Fri, 2023-07-21 at 14:11 +0100, Matthew Malcomson wrote:
> My understanding is that this is not a hardware bug and that it's
> specified that rounding does not happen on the multiply "sub-part" in
> `FNMSUB`, but rounding happens on the `FMUL` that generates some input
> to it.
AFAIK the C st
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 -
Please configure your mail client to send the patch as plain text (not
HTML, and don't replace a tab with 8 whitespaces, etc). If it's not
possible, send the patch as an attachment.
And, it's better to separate the changes in
https://reviews.llvm.org/D127098 and struct_kernel_stat_sz into two
pat
Again, please send patch as plain text.
On Fri, 2022-07-01 at 08:18 +, Dimitrije Milosevic wrote:
> When we use cross toolchains, in which the GCC libraries are not
> installed within a designated system root, the shared sanitizer
> libraries link against libstdc++.so* within the same librarie
On Fri, 2022-07-01 at 12:40 +, Dimitrije Milosevic wrote:
> Fix kernel_stat structure size for non-Android 32-bit Mips.
> LLVM currently has this value for the kernel_stat structure size,
> as per compiler-rt/lib/sanitizer-common/sanitizer_platform_limits_posix.h.
> This also resolves one of th
On Fri, 2022-07-01 at 12:40 +, Dimitrije Milosevic wrote:
> Building the ASAN for the n32 MIPS ABI currently fails, due to a few reasons:
> - defined(__mips64), which is set solely based on the architecture type
> (32-bit/64-bit),
> was still used in some places. Therefore, defined(__mips64)
On Sat, 2022-07-02 at 15:39 +0800, Lulu Cheng wrote:
> diff --git a/gcc/common/config/loongarch/loongarch-common.cc
> b/gcc/common/config/loongarch/loongarch-common.cc
> index b6cbd84b873..f8b4660fabf 100644
> --- a/gcc/common/config/loongarch/loongarch-common.cc
> +++ b/gcc/common/config/loongar
On Sat, 2022-07-02 at 16:35 +0800, Lulu Cheng wrote:
> 在 2022/7/2 下午4:24, Xi Ruoyao 写道:
> >
> > I'll commit the patch with the hook removed after another regtest on
> > loongarch64-linux-gnu. I just rebuilt the entire system on my
> > 3A5000,
> > so I need some time to set it up. Expectation tim
On Mon, 2022-07-04 at 14:25 +0800, Lulu Cheng wrote:
> > How do you think about the suggestion from Richard about a backport into
> > gcc-12 branch? Normally we don't backport behavior changes, but making
> > 12.1 the only exception seems compelling.
>
> I agree with you and Richard.
>
> Thanks
Document a behavior change in r12-8546. Ok for wwwdocs?
---
htdocs/gcc-12/changes.html | 26 ++
1 file changed, 26 insertions(+)
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index ae03c3c6..ef957204 100644
--- a/htdocs/gcc-12/changes.html
+++ b/ht
On Mon, 2022-07-04 at 14:28 +, Dimitrije Milosevic wrote:
> On Saturday, June 11, 2022 2:03 PM, Xi wrote:
> > Just tried TSAN_SUPPORTED=yes with asynchronous unwind tables
> > enabled,
> > but I got some strange test failures for tls_race.c:
> >
> > FAIL: c-c++-common/tsan/tls_race.c -O0 ou
On Mon, 2022-07-04 at 21:21 -0700, Fangrui Song wrote:
> Clang considers that asan/msan/tsan/dataflow/etc enables
> -fasynchronous-unwind-tables by default so I assume this GCC change is
> fine.
I agree it's fine, but the problem is TSAN is currently "unsupported"
within GCC (i. e. when you build
On Tue, 2022-07-05 at 12:51 +0800, Xi Ruoyao via Gcc-patches wrote:
> I agree it's fine, but the problem is TSAN is currently "unsupported"
> within GCC (i. e. when you build gcc libtsan is not built). So it
> does
> not make any benefit to commit this change before m
On Mon, 2022-07-04 at 21:21 -0700, Fangrui Song wrote:
> > >
> > > > FAIL: c-c++-common/tsan/tls_race.c -O0 output pattern test
> > > > Output was:
> > > > ThreadSanitizer: CHECK failed: tsan_platform_linux.cpp:452
> > > > "((thr_end)) <= ((tls_addr + tls_size))" (0xffec35f8c0,
> > > > 0xffec3
On Wed, 2022-07-06 at 11:34 +, Dimitrije Milosevic wrote:
> Ping. :)
> This change just landed on LLVM (see
> https://reviews.llvm.org/rG5d8077565e4196efdd4ed525a64c11a96d5aa5dd).
> Unfortunately, I do not have commit access, so if anyone can commit it, that
> would be great!
> Here is the pa
On Thu, 2022-07-07 at 02:11 +0800, Xi Ruoyao via Gcc-patches wrote:
> On Wed, 2022-07-06 at 11:34 +, Dimitrije Milosevic wrote:
> > Ping. :)
> > This change just landed on LLVM (see
> > https://reviews.llvm.org/rG5d8077565e4196efdd4ed525a64c11a96d5aa5dd)
> > .
>
We were generating some unnecessary instructions for integer division.
These two patches improve the code generation to compile
template T div(T a, T b) { return a / b; }
into a single division instruction (along with a return instruction of
course) as we expected for T in {int32_t, uint32_t
Currently in the description of LoongArch integer division instructions,
the output is marked as earlyclobbered ('&'). It's necessary when
loongarch_check_zero_div_p() because clobbering operand 2 (divisor) will
make the checking for zero divisor impossible.
But, for -mno-check-zero-division (the
Like add.w/sub.w/mul.w, div.w/mod.w/div.wu/mod.wu also sign-extend the
output on LA64. But, LoongArch v1.00 mandates that the inputs of 32-bit
division to be sign-extended so we have to expand 32-bit division into
RTL sequences.
We defined div.w/mod.w/div.wu/mod.wu as a (DI, DI) -> SI instruction
On Thu, 2022-07-07 at 16:31 +0800, WANG Xuerui wrote:
> IMO it's better to also state which problem this change is meant to
> solve (i.e. your intent), better yet, with an appropriate bugzilla
> link.
And/or add a testcase (which FAILs without this change) into
gcc/testsuite/gcc.target/loongarch
On Thu, 2022-07-07 at 18:30 +0800, Lulu Cheng wrote:
/* snip */
> diff --git a/gcc/testsuite/gcc.target/loongarch/prolog-opt.c
> b/gcc/testsuite/gcc.target/loongarch/prolog-opt.c
> new file mode 100644
> index 000..c7bd71dde93
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/loongarch/pr
I think this should be obvious. Ok for trunk and gcc-12 branch?
(Note: this bug really amazed me. It's just a simple typo and all of us
failed to spot it reviewing the LoongArch port. Incredibly, it can be
reproduced with such a simple test case (in the patch) but did not blow
the entire system
v2: Move one portable test to gcc.c-torture so it will be tested with
all optimization levels. And it might be helpful if the engineer of the
next GCC port makes a similar typo :).
-- >8 --
(mult (sign_extend:DI rj:SI) (sign_extend:DI rk:SI)) should be
"mulw.d.w", not "mul.d".
gcc/ChangeLog:
On Fri, 2022-07-08 at 21:42 -0400, Hans-Peter Nilsson wrote:
> On Fri, 1 Jul 2022, Dimitrije Milosevic wrote:
>
> > Fix kernel_stat structure size for non-Android 32-bit Mips.
> > LLVM currently has this value for the kernel_stat structure size,
> > as per compiler-rt/lib/sanitizer-
> > common/san
v3: Relax scan-assembler pattern in test case mulw_d_w.c. It's because
multiplication is Abelian and the compiler may switch the order of
operands in the future.
-- >8 --
(mult (sign_extend:DI rj:SI) (sign_extend:DI rk:SI)) should be
"mulw.d.w", not "mul.d".
gcc/ChangeLog:
* config/lo
On Sun, 2022-07-10 at 09:45 +0800, Lulu Cheng wrote:
>
> 在 2022/7/9 上午10:56, Xi Ruoyao 写道:
> > v3: Relax scan-assembler pattern in test case mulw_d_w.c. It's
> > because
> > multiplication is Abelian and the compiler may switch the order of
> > operands in the future.
> > -- >8 --
> >
> > (mult
On Sun, 2022-07-10 at 10:20 +0800, Lulu Cheng wrote:
>
> 在 2022/7/7 上午10:23, Xi Ruoyao 写道:
> > We were generating some unnecessary instructions for integer
> > division.
> > These two patches improve the code generation to compile
> >
> > template T div(T a, T b) { return a / b; }
> >
> >
On Tue, 2022-07-12 at 06:42 +, Dimitrije Milosevic wrote:
> Hi Hans-Peter,
> You're right, this is not ok for the O32 ABI. Your change however, broke the
> functionality
> for the N32 ABI. AFAIK, the changes like this should go through LLVM first
> (yours didn't),
> so I will send out a revie
On Tue, 2022-07-12 at 06:42 +, Dimitrije Milosevic wrote:
> I will send out a review, covering both 32 ABIs, meaning that both O32
> and N32 ABIs will be working properly.
Please CC me (@xry111) in LLVM review.
By the way, if you have some spare time, you can also add the value for
Musl (all
The change seems too large. It would be better to split it into
multiple commits (for example, just 3 commits for 1,2,3 below).
On Tue, 2022-07-19 at 21:08 +0800, Lulu Cheng wrote:
> 1. The original LA macro instruction is split into two instructions to
> obtain the address of the symbol if e
LGTM. Requiring permission to push.
> +const unsigned struct_kernel_stat_sz =
> + SANITIZER_ANDROID
> + ? FIRST_32_SECOND_64(104, 128)
> + : FIRST_32_SECOND_64((_MIPS_SIM == _ABIN32) ? 160 : 144, 216);
These values matches sizeof(struct stat) on gcc230, so should be
correct:
xr
Gentle ping :).
On Thu, 2022-06-30 at 12:22 +0800, Xi Ruoyao wrote:
> In libsanitizer code, the size of some GNU libc data structure
> (notably,
> struct stat) is hard coded. These sizes may trigger a static assert
> buidling against another libc.
>
> Just make non-GNU libc targets UNSUPPORTED n
+Xuerui (his English is much better than mine).
On Tue, 2022-07-26 at 15:21 +0800, Lulu Cheng wrote:
> Hi,
> Recently we added split symbol support, changed in r13-1834.
> It is ok for wwwdocs?
> +LoongArch
> +
> + The option -mexplicit-relocs has been added, this indicate
I think "added an
On Tue, 2022-07-26 at 19:42 +0800, Lulu Cheng wrote:
> 在 2022/7/26 下午5:44, Xi Ruoyao 写道:
> >
> > > + whether the la.* macro instructions will be generated when
> > > + loading symbolic addresses.
> > > + This feature requires binutils version 2.40 or later. If you want to
> > > use the
> > >
> > Maybe we can add a check in gcc/configure.ac to see if gcc_cv_ld
> > supports %got_pc_hi20 and adjust the default for -m[no]-explicit-relocs?
> I think this is a good way, I'll look at adding a check.
The following should work. I've tested it locally by building GCC with
both old (2.38 with
On Wed, 2022-07-27 at 09:34 +0800, Lulu Cheng wrote:
> > -- >8 --
> >
> > The assembly produced with -mexplicit-relocs is not supported by gas
> > <=
> > 2.39. Check if the assembler supports explicit relocations and set
> > the
> > default accordingly.
> Looks good to me.
Pushed r13-1851.
On Wed, 2022-07-27 at 06:41 +, Dimitrije Milosevic wrote:
> Gentle ping, requiring someone to push this change, as I do not have
> commit access. :)
Do you know someone very familiar with MIPS and GCC and capable as a
port maintainer? An active MIPS port maintainer will make the situation
bet
Document newly introduced -m[no-]explicit-relocs options. Ok for trunk?
-- >8 --
gcc/ChangeLog:
* doc/invoke.texi: Document -m[no-]explicit-relocs for
LoongArch.
---
gcc/doc/invoke.texi | 12
1 file changed, 12 insertions(+)
diff --git a/gcc/doc/invoke.texi b/gcc/
On Wed, 2022-07-27 at 16:47 +0800, Lulu Cheng wrote:
> > "Use or do not use assembler relocation operators when dealing with
> > symbolic addresses. The alternative is to use assembler macros
> > instead, which may limit optimization.
> >
> > The default value for the option is determined dur
On Wed, 2022-07-27 at 17:57 +0800, WANG Xuerui wrote:
> On 2022/7/27 17:28, Lulu Cheng wrote:
> >
> >
> > 在 2022/7/27 下午5:15, Xi Ruoyao 写道:
> > > On Wed, 2022-07-27 at 16:47 +0800, Lulu Cheng wrote:
> > >
> > > > > "Use or do not use assembler relocation operators when dealing with
> > > > > s
On Thu, 2022-07-28 at 10:59 +0800, Lulu Cheng wrote:
> > The ASM_PREFERRED_EH_DATA_FORMAT macro before and after modification
> > is
> as follows:
> #define ASM_PREFERRED_EH_DATA_FORMAT(CODE, GLOBAL) \
> - (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_absptr)
> + (((GLOBAL) ? DW_EH_PE_indire
On Fri, 2022-07-29 at 10:43 +0800, Lulu Cheng wrote:
> .eh_frame DW_EH_PE_pcrel encoding format is not supported by gas <= 2.39.
> Check if the assembler support DW_EH_PE_PCREL encoding and define .eh_frame
> encoding type.
>
> gcc/ChangeLog:
>
> * config.in: Regenerate.
> * conf
On Fri, 2022-07-29 at 11:51 +0800, Lulu Cheng wrote:
> > > gcc/ChangeLog:
> > >
> > > * config.in: Regenerate.
> > > * config/loongarch/loongarch.h (ASM_PREFERRED_EH_DATA_FORMAT):
> > > Select the value of the macro definition according to whether
> > > HAVE_AS_EH_F
Background:
https://lore.kernel.org/loongarch/d7670b60-2782-4642-995b-7baa01779...@loongson.cn/T/#e1d47e2fe185f2e2be8fdc0784f0db2f644119379
Question: Do you have a better name than "addr_global"?
Alternatives:
1. Just use "-mno-explicit-relocs -mla-local-with-abs" for kernel
modules. It's stup
Don't look at V1 patch: I selected wrong file and sent a draft with bugs
mistakenly.
Background:
https://lore.kernel.org/loongarch/d7670b60-2782-4642-995b-7baa01779...@loongson.cn/T/#e1d47e2fe185f2e2be8fdc0784f0db2f644119379
Question: Do you have a better name than "addr_global"?
Alternatives:
Change v2 to v3:
- Disable section anchor for addr_global symbols.
- Use -O2 in test to make sure section anchor is disabled.
--
Background:
https://lore.kernel.org/loongarch/d7670b60-2782-4642-995b-7baa01779...@loongson.cn/T/#e1d47e2fe185f2e2be8fdc0784f0db2f644119379
Question: Do you have a be
Changes v3 -> v4:
* Use "movable" as the attribute name as Huacai says it's already used
in downstream GCC fork.
* Remove an inaccurate line from the doc. (Initially I tried to
implement a "model(...)" like IA64 or M32R. Then I changed my mind
but forgot to remove the line copied from M
Changes v4 -> v5: Fix changelog. No code change.
Changes v3 -> v4:
* Use "movable" as the attribute name as Huacai says it's already used
in downstream GCC fork.
* Remove an inaccurate line from the doc. (Initially I tried to
implement a "model(...)" like IA64 or M32R. Then I changed my
On Sat, 2022-07-30 at 14:22 +0100, Maciej W. Rozycki wrote:
> On Mon, 6 Jun 2022, Dimitrije Milosevic wrote:
>
> > * config/mips/mips.cc (mips_asan_shadow_offset): Reformat
> > to handle the N32 ABI.
>
> That's not what the change does.
>
> > * config/mips/mips.h (SUBTAR
Is it OK for trunk or I need to change something?
By the way, I'm seeking a possibility to include this into 12.2. Then
we leaves only 12.1 without this attribute, and we can just say
"building the kernel needs GCC 12.2 or later".
On Mon, 2022-08-01 at 18:07 +0800, Xi Ruoyao wrote:
> Changes v4
On Wed, 2022-08-03 at 10:55 +0800, chengl...@loongson.cn wrote:
> I think there is no problem with this patch。But I have a question. The
> visibility attribute works, so is it necessary to add the moveable
> attribute?
1. My use of -fPIC and visibility is not in the way ELF visibility has
been des
On Wed, 2022-08-03 at 10:59 +0800, WANG Xuerui wrote:
> I don't think mindlessly caring for vendor forks is always correct. In
> fact I find the name "movable" too generic, and something like
> "force_got_access" could be better.
The problem is "what will this behave *if* we later add some code
On Wed, 2022-08-03 at 11:10 +0800, Xi Ruoyao via Gcc-patches wrote:
> > I'd like to wait for the kernel team to test the performance data of
> > the two implementations before deciding whether to support this
> > attribute.
> >
> > What do you think？
>
&
On Fri, 2022-08-05 at 09:05 +0800, Lulu Cheng wrote:
> I'm working on the implementation of specifing attributes of variables for
> other architectures.
> If the address is obtained through the GOT table and 4 instructions, there is
> not much difference in performance.
In this case I still pref
On Fri, 2022-08-05 at 10:38 +0800, Lulu Cheng wrote:
> > > I'm working on the implementation of specifing attributes of variables
> > > for other architectures.
> > > If the address is obtained through the GOT table and 4 instructions,
> > > there is not much difference in performance.
> > In th
On Fri, 2022-08-05 at 10:51 +0800, Xi Ruoyao via Gcc-patches wrote:
> > If it is accessed through the GOT table, dynamic relocation is required
> > when the module is loaded.
>
> Dynamic relocation is required when the module is loaded anyway. The
> .ko modules are act
On Fri, 2022-08-05 at 11:34 +0800, Xi Ruoyao via Gcc-patches wrote:
> Or maybe we should just use a PC-relative addressing with 4 instructions
> instead of GOT for -fno-PIC?
Not possible, Glibc does not support R_LARCH_PCALA* relocations in
ld.so. So we still need a -mno-got (or som
On Fri, 2022-08-05 at 12:01 +0800, Lulu Cheng wrote:
>
> 在 2022/8/5 上午11:45, Xi Ruoyao 写道:
>
>
>
>
> > On Fri, 2022-08-05 at 11:34 +0800, Xi Ruoyao via Gcc-patches wrote:
> >
> >
> >
> >
> >
> > > Or maybe we should just us
On Fri, 2022-08-05 at 15:58 +0800, Lulu Cheng wrote:
> I think the model of precpu is not very easy to describe.
> model(got)?model(global)?
> I also want to use attribute model and -mcmodel together, but this is just an
> initial idea,
> what do you think?
It seems I had some misunderstanding
Sorry for late reply, I'm rebuilding my entire Linux system (from
scratch) for Glibc-2.36 and Binutils-2.39 update and I just reached the
mail client.
On Mon, 2022-08-08 at 12:53 +0800, Lulu Cheng wrote:
> I still think it makes a little bit more sense to put attribute(model)
> and -mcmodel togeth
On Tue, 2022-08-09 at 21:03 +0800, Lulu Cheng wrote:
>
> 在 2022/8/9 下午7:30, Xi Ruoyao 写道:
>
>
>
>
> > Sorry for late reply, I'm rebuilding my entire Linux system (from
> > scratch) for Glibc-2.36 and Binutils-2.39 update and I just reached the
> > mail client.
> >
> > On Mon, 2022-08-08 at 1
On Mon, 2023-08-07 at 12:01 +0800, chenxiaolong wrote:
> +/* Count the number of functions with "q" as the suffix */
> +static int MATHQ_NUMS=(int)LARCH_MAX_FTYPE_MAX-(int)LARCH_BUILTIN_HUGE_VALQ;
This is obviously not the GCC coding standard... It should have some
white spaces:
static int MATHQ
On Tue, 2023-08-08 at 10:09 +0800, chenxiaolong wrote:
> +/* Count the number of functions with "q" as the suffix. */
> +const int MATHQ_NUMS=(int)LARCH_MAX_FTYPE_MAX-(int)LARCH_BUILTIN_HUGE_VALQ;
Format issue still not fixed.
> +__float128 nanq (const char * str)
> +{
> + union _FP_UNION_
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 them
On Sun, 2023-08-06 at 20:49 +0800, Jiajie Chen via Gcc-patches wrote:
> When loongarch_arch_target is called, la_target has not been
> initialized, thus the macro LARCH_ACTUAL_ARCH always equals to zero.
>
> This commit fixes by expanding the macro and reading the latest value.
> It permits -march
On Wed, 2023-08-09 at 19:46 +0800, Jiajie Chen wrote:
> + builtin_define ("_ABILP32=3");
> + builtin_define ("_LOONGARCH_SIM=_ABILP32");
Let's remove them. These MIPS-style definitions are deprecated:
https://github.com/loongson/LoongArch-Documentation/pull/28.
Unfortunately for LP64 A
On Wed, 2023-08-09 at 19:46 +0800, Jiajie Chen wrote:
> LoongArch32 only provides basic ll/sc instructions for atomic
> operations. Mark am* atomic instructions as 64-bit only.
I'd prefer using a different symbol, say TARGET_LOONGARCH_AM here. Then
it would be easier to adjust the code if we have
On Thu, 2023-08-10 at 09:11 +0800, liuhongt via Gcc-patches wrote:
> Currently we have 3 different independent tunes for gather
> "use_gather,use_gather_2parts,use_gather_4parts",
> similar for scatter, there're
> "use_scatter,use_scatter_2parts,use_scatter_4parts"
>
> The patch support 2 standard
On Thu, 2023-08-10 at 15:04 +0200, Stefan Schulze Frielinghaus via Gcc-
patches wrote:
> In the former fix in commit 41ef5a34161356817807be3a2e51fbdbe575ae85 I
> completely missed the fact that the normal form of a generated constant for a
> mode with fewer bits than in HOST_WIDE_INT is a sign exte
On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie wrote:
> LoongArch processors may not support memory accesses without natural
> alignments. Building libraries with -mstrict-align may help with
> toolchain binary compatiblity and performance on these implementations
> (e.g. Loongson 2K1000LA).
I don
On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie wrote:
> The configure script and the GCC driver are updated so that
> it is easier to customize and control GCC builds for targeting
> different LoongArch implementations.
>
> * Support options for LoongArch SIMD extensions:
> new configure options
On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie wrote:
> These are exported according to the LoongArch Toolchain Conventions[1]
> as a replacement of the obsolete "_LOONGARCH_{ARCH,TUNE}" macros,
> which are expanded to strings representing the actual architecture
> and microarchitecture of the targe
On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie wrote:
> loongarch64)
> - tune_pattern="loongarch64|la464"
> - tune_default="la464"
> + tune_pattern="native|abi-default|loongarch64|la464"
I think we can remove tune_pat
On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie 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
> ABI-specific subdirs (e.g. base/lp64d) of t
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
> > ABI-specific subdirs (e.g. base/lp
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 / -msimd={none,lsx,lasx}.
I suggest to rename --with-simd= to --with-ext= and accept a comma-
separate
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
> > > installation since the default ABI may change.
On Mon, 2023-08-14 at 16:44 +0800, Yujie Yang wrote:
> I assume we all want:
>
> (1) -mlasx -mlsx -> enable LSX and LASX
> (2) -mlasx -mno-lsx -> disable LSX and LASX
> (3) -mno-lsx -mlasx -> enable LSX and LASX
Yes.
> Unless we declare -mlsx / -mlasx as driver deferred, AFAIK there is no oth
On Mon, 2023-08-14 at 16:57 +0800, Yujie Yang wrote:
> On Mon, Aug 14, 2023 at 04:49:11PM +0800, Xi Ruoyao wrote:
> > On Mon, 2023-08-14 at 16:44 +0800, Yujie Yang wrote:
> > > I assume we all want:
> > >
> > > (1) -mlasx -mlsx -> enable LSX and LASX
> > > (2) -mlasx -mno-lsx -> disable LSX and
On Mon, 2023-08-14 at 18:18 +0800, Yujie Yang wrote:
> On Mon, Aug 14, 2023 at 03:48:53PM +0800, Xi Ruoyao wrote:
> > 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:
>
I guess there is a merge conflict with Yujie's "-msimd=" patch and you
may need to collaborate to resolve it. Maybe just add -msimd in this
series.
On Tue, 2023-08-15 at 09:05 +0800, Chenghui Pan wrote:
> From: Lulu Cheng
>
> gcc/ChangeLog:
>
> * config/loongarch/genopts/loongarch-stri
On Mon, 2023-08-14 at 19:16 +0800, Xi Ruoyao wrote:
> On Mon, 2023-08-14 at 18:18 +0800, Yujie Yang wrote:
> > On Mon, Aug 14, 2023 at 03:48:53PM +0800, Xi Ruoyao wrote:
> > > 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:
> >
Please fix code style (this is the third time I say it and I'm really
frustrated now). GCC is a project, it's not a student homework so style
matters. And it's not so difficult to fix the style: for a new file you
can use "clang-format --style GNU -i filename.c" to do the work
automatically.
On
The implementation fails to handle this test case properly:
typedef double __attribute__((vector_size(32))) v4df;
void use1(double);
__attribute__((noipa)) double use(double)
{
register double x asm("f24") = 114.514;
__asm__("" : "+f" (x));
return x;
}
void test(void)
{
1 - 100 of 548 matches
Mail list logo
