There are two reasons for removing this macro definition:
1. The default in the assembler is to use the nop instruction for filling.
2. For assembly directives: .align [abs-expr[, abs-expr[, abs-expr]]]
The third expression it is the maximum number of bytes that should be
skipped by this alig
在 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 parameters
(also including -falign-jumps and -falign-lables ) on performance. So
before the
If the $ra register is modified during the jump to the jump table, the hardware
branch prediction function will be broken, resulting in a significant increase
in the branch false prediction rate and affecting performance.
gcc/ChangeLog:
* config/loongarch/loongarch.md: Change register con
在 2023/6/7 上午11:26, WANG Xuerui 写道:
Hi,
On 2023/6/7 10:31, Lulu Cheng wrote:
If the $ra register is modified during the jump to the jump table,
the hardware
branch prediction function will be broken, resulting in a significant
increase
in the branch false prediction rate and affecting
在 2023/6/7 下午3:37, WANG Xuerui 写道:
On 2023/6/7 11:36, Lulu Cheng wrote:
在 2023/6/7 上午11:26, WANG Xuerui 写道:
Hi,
On 2023/6/7 10:31, Lulu Cheng wrote:
If the $ra register is modified during the jump to the jump table,
the hardware
branch prediction function will be broken, resulting in a
Micro-architecture unconditionally treats a "jr $ra" as "return from
subroutine",
hence doing "jr $ra" would interfere with both subroutine return prediction and
the more general indirect branch prediction.
Therefore, a problem like PR110136 can cause a significant increase in branch
error
predi
在 2023/6/12 下午5:19, Xi Ruoyao 写道:
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
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-byte label alignment together with 32-byte
function alignment gives best results in te
Micro-architecture unconditionally treats a "jr $ra" as "return from
subroutine",
hence doing "jr $ra" would interfere with both subroutine return prediction and
the more general indirect branch prediction.
Therefore, a problem like PR110136 can cause a significant increase in branch
error
predi
From: chenxiaolong
Pushed r14-1831.
During the regression testing of the LoongArch architecture GCC, it was found
that the tests in the pr90883.C file failed. The problem was modulated and
found that the error was caused by setting the macro LARCH_CALL_RATIO to a too
large value. Combined with t
Pushed to trunk and gcc-12 gcc-13.
r14-1866
r13-7448
r12-9698
在 2023/6/15 上午9:30, Lulu Cheng 写道:
Micro-architecture unconditionally treats a "jr $ra" as "return from
subroutine",
hence doing "jr $ra" would interfere with both subroutine return prediction and
th
#define TARGET_DEFAULT_TARGET_FLAGS MASK_CHECK_ZERO_DIV
-
I think this modifications are needed, and there is no problem with the
rest.
Thanks!
Lulu Cheng
在 2022/7/2 下午4:24, Xi Ruoyao 写道:
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
在 2022/7/3 上午11:06, Xi Ruoyao 写道:
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
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_compute_frame_info):
Modify fp_sp_offset and gp_sp_offset's calculation method,
when frame->mask or frame->fmask is zero, don't minus UNITS_PER_WORD
or UNITS_PER_FP_REG.
---
gcc/config/loongarch/loongarch.cc
Under the LA architecture, when the stack is dropped too far, the process
of dropping the stack is divided into two steps.
step1: After dropping the stack, save callee saved registers on the stack.
step2: The rest of it.
The stack drop operation is optimized when frame->total_size minus
frame->sp_
update testsuite.
--
Under the LA architecture, when the stack is dropped too far, the process
of dropping the stack is divided into two steps.
step1: After dropping the stack, save callee saved registers on the stack.
step2: The rest of it.
The stack drop operation is op
在 2022/7/7 下午7:51, Xi Ruoyao 写道:
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
在 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; }
into a single division instruction (along with a return instruction of
course) as
Pushed for trunk and gcc-12.
r13-1569-gaa8fd7f65683ef.
r12-8558-ge623829c18ec29
Under the LA architecture, when the stack is dropped too far, the process
of dropping the stack is divided into two steps.
step1: After dropping the stack, save callee saved registers on the stack.
s
在 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 (sign_extend:DI rj:SI) (sign_extend:DI rk:SI)) should be
"mulw.d.w", not "mul.d".
在 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; }
into a single division instruction (along with a return instruction of
course) as
atches applied to binutils to build.
https://sourceware.org/pipermail/binutils/2022-July/121849.html
https://sourceware.org/pipermail/binutils/2022-July/121850.html
https://sourceware.org/pipermail/binutils/2022-July/121851.html
https://sourceware.org/pipermail/binutils/2022-July/121852.html
https://
1. The original LA macro instruction is split into two instructions to
obtain the address of the symbol if enable '-mexplicit-relocs'.
2. Currently, '-mcmodel=' only supports 'normal' mode, because other mode
behaviors are not yet determined. This function is gradually improved
by the subs
Some R_LARCH_64 in section .eh_frame will to generate R_LARCH_NONE, we
change relocation to R_LARCH_32_PCREL from R_LARCH_64 in setction .eh_frame
and not generate dynamic relocation for R_LARCH_32_PCREL.
gcc/ChangeLog:
* config/loongarch/loongarch.h (ASM_PREFERRED_EH_DATA_FORMAT):
在 2022/7/19 下午10:29, Xi Ruoyao 写道:
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
g/pipermail/binutils/2022-July/121935.html
[5]https://sourceware.org/pipermail/binutils/2022-July/121936.html
[6]https://sourceware.org/pipermail/binutils/2022-July/121938.html
[7]https://sourceware.org/pipermail/binutils/2022-July/121939.html
Lulu Cheng (3):
LoongArch: Subdivision symbo
1. Remove cModel type support other than normal.
2. The method that calls global functions from 'la.global + jirl' to 'bl'
when build with '-fplt'.
gcc/ChangeLog:
* config/loongarch/constraints.md (a): Delete the constraint.
(b): A constant call not local address.
(h):
Some R_LARCH_64 in section .eh_frame will to generate R_LARCH_NONE, we
change relocation to R_LARCH_32_PCREL from R_LARCH_64 in setction .eh_frame
and not generate dynamic relocation for R_LARCH_32_PCREL.
gcc/ChangeLog:
* config/loongarch/loongarch.h (ASM_PREFERRED_EH_DATA_FORMAT):
Add compilation option '-mexplicit-relocs', and if enable '-mexplicit-relocs'
the symbolic address load instruction 'la.*' will be split into two
instructions.
This ckompilation option enabled by default.
gcc/ChangeLog:
* common/config/loongarch/loongarch-common.cc:
Enable '-fsec
在 2022/7/19 下午9:08, Lulu Cheng 写道:
1. The original LA macro instruction is split into two instructions to
obtain the address of the symbol if enable '-mexplicit-relocs'.
2. Currently, '-mcmodel=' only supports 'normal' mode, because other mode
behavior
Hi,
Recently we added split symbol support, changed in r13-1834.
It is ok for wwwdocs?
Thanks!
Lulu Cheng
---
htdocs/gcc-13/changes.html | 21 +
1 file changed, 21 insertions(+)
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 57bd8724
在 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
+ older version of bintuils, add compiler parameters
+ -mno-explicit-relocs at compi
在 2022/7/26 下午7:32, Gerald Pfeifer 写道:
On Tue, 26 Jul 2022, Lulu Cheng wrote:
+LoongArch
+
+ The option -mexplicit-relocs has been added, this indicates
+ whether the la.* macro instructions will be generated when
+ loading symbolic addresses.
How about making this "...has been adde
在 2022/7/26 下午8:01, Xi Ruoyao 写道:
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
在 2022/7/26 下午10:15, Xi Ruoyao 写道:
The following should work. I've tested it locally by building GCC with
both old (2.38 with patch) and new (trunk) Binutils. Ok for trunk?
I simply checked as instead of ld. If as supports explicitly
relocations, the produced .o file won't be supported by a
在 2022/7/27 下午3:21, WANG Xuerui 写道:
Hi,
On 2022/7/27 15:06, Xi Ruoyao wrote:
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 +++
在 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
symbolic addresses. The alternative is to use assembler macros
instead, which may limit optimization.
The default value fo
在 2022/7/26 下午8:01, Xi Ruoyao 写道:
On Tue, 2022-07-26 at 19:42 +0800, Lulu Cheng wrote:
在 2022/7/26 下午5:44, Xi Ruoyao 写道:
Should we indicate that our .eh_frame section format has changed?
I don't really understand C++ exception handling, so: does the change
breaks something? For ex
在 2022/7/28 下午6:41, Xi Ruoyao 写道:
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
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_indirect : 0) | DW_EH_PE_pcrel | DW_EH_PE_sdata4)
Use the following tests
在 2022/7/29 上午11:18, Xi Ruoyao 写道:
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
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_indirect : 0) | DW_EH_PE_pcrel | DW_EH_PE_sdata4)
Use the following tests t
在 2022/7/29 下午12:02, Lulu Cheng 写道:
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_indirect : 0) | DW_EH_PE_pcrel
在 2022/7/30 上午1:17, Xi Ruoyao 写道:
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/#e1d47e2fe185f2e2be8fdc0784f0db2f
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.
Is it more reasonable for us to refer to the implementation of the model
attribute un
在 2022/8/5 上午9:28, Xi Ruoyao 写道:
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 differen
在 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 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 n
在 2022/8/5 下午2:03, Xi Ruoyao 写道:
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 use a PC-relative addressing with 4 instructions
instead of GOT
在 2022/8/5 下午3:41, WANG Xuerui 写道:
On 2022/8/5 15:19, Lulu Cheng wrote:
在 2022/8/5 下午2:03, Xi Ruoyao 写道:
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
在 2022/8/5 下午5:53, Xi Ruoyao 写道:
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
在 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 12:53 +0800, Lulu Cheng wrote:
I still think it makes a little bit more sense t
thread.c:
__attribute__ ((tls_model ("global-dynamic"))) __thread int a;
void
test (void)
{
a = 10;
}
Compile the tests with -fno-plt, error message is as follows:
thread.c: In function 'test':
thread.c:7:1: error: unrecognizable insn:
7 | }
| ^
(call_insn/u 7 6 8 2 (parallel [
LoongArch's microstructure ensures cache consistency by hardware.
Due to out-of-order execution, ibar is required to ensure the visibility of the
store (invalidated icache) executed by this CPU before ibar (to the instance).
ibar will not invalidate the icache, so the start and end parameters are n
add yangyujie.
在 2023/2/13 下午6:38, Xi Ruoyao 写道:
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 bot
Hi,
在 2023/2/15 下午6:42, WANG Xuerui 写道:
Hi,
On 2023/2/13 18:38, Xi Ruoyao wrote:
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=l
Pushed r13-6126 and cherry picked to r12-9187.
在 2023/2/17 上午9:41, Lulu Cheng 写道:
Hi,
在 2023/2/15 下午6:42, WANG Xuerui 写道:
Hi,
On 2023/2/13 18:38, Xi Ruoyao wrote:
Multiarch tuple will be coded in file or directory names in
multiarch-aware distros, so one ABI should have only one multiarch
Like la264 only has 40 effective bits of virtual address space.
When TRY_EMPTY_VM_SPACE is set to 0x80, it just exceeds
the range of 40-bit virtual address, causing the mmap mapping
to fail, thus causing the pch function to fail. To be compatible
with this situation set the macro to 0x1
在 2023/2/21 下午3:41, Xi Ruoyao 写道:
On Tue, 2023-02-21 at 15:20 +0800, Lulu Cheng wrote:
Like la264 only has 40 effective bits of virtual address space.
I'm OK with the change. But the VA length is configurable building the
kernel. Is there any specific reason LA264 has to use the 4
在 2023/2/21 下午9:56, WANG Xuerui 写道:
Hi,
On 2023/2/21 21:03, Lulu Cheng wrote:
在 2023/2/21 下午3:41, Xi Ruoyao 写道:
On Tue, 2023-02-21 at 15:20 +0800, Lulu Cheng wrote:
Like la264 only has 40 effective bits of virtual address space.
I'm OK with the change. But the VA length is configu
在 2023/2/22 下午5:35, WANG Xuerui 写道:
On 2023/2/22 17:30, Lulu Cheng wrote:
在 2023/2/21 下午9:56, WANG Xuerui 写道:
Hi,
On 2023/2/21 21:03, Lulu Cheng wrote:
在 2023/2/21 下午3:41, Xi Ruoyao 写道:
On Tue, 2023-02-21 at 15:20 +0800, Lulu Cheng wrote:
Like la264 only has 40 effective bits of
The PCH mechanism first tries to map the .gch file to the virtual memory
space pointed to by TRY_EMPTY_VM_SPACE during the compilation process.
The original value of TRY_EMPTY_VM_SPACE macro is 0x80,
but like la464 only has 40 bits of virtual address space, this value
just exceeds the addr
Pushed to r13-6353.
在 2023/2/23 下午5:29, Lulu Cheng 写道:
The PCH mechanism first tries to map the .gch file to the virtual memory
space pointed to by TRY_EMPTY_VM_SPACE during the compilation process.
The original value of TRY_EMPTY_VM_SPACE macro is 0x80,
but like la464 only has 40 bits
在 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 case fixes. Ok for trunk?
Ok.
Lulu: if you don't object I'll push these two in this week.
I tried to bisect for the exact
在 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
registers. This option should not change the FP calling convention
unless it's necessary."
Though not explicitly stated, the rationale of this
在 2023/3/6 下午4:02, Xi Ruoyao 写道:
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
reproduced the problem of the second mail.
Is there a
在 2023/3/6 下午4:18, Xi Ruoyao 写道:
On Mon, 2023-03-06 at 16:12 +0800, Lulu Cheng wrote:
Has the first patch been merged into the main branch yet?
I think there is one more test case that needs to be modified:
--- a/gcc/testsuite/gcc.target/loongarch/prolog-opt.c
+++ b/gcc/testsuite/gcc.target
LoongArch 32-bit instruction set does not support crc* and crcc* instructions.
gcc/ChangeLog:
* config/loongarch/larchintrin.h (__crc_w_b_w): Add macros for control.
(__crc_w_h_w): Likewise.
(__crc_w_w_w): Likewise.
(__crcc_w_b_w): Likewise.
(__crcc_w_h_w):
在 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 coincidence; it's entirely possible for a future product
iteration to introduce such functionality. It's not like the CRC*.W.W
在 2023/3/13 下午3:30, WANG Xuerui 写道:
On 2023/3/13 13:14, Xi Ruoyao wrote:
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
o
An empty struct type that is not non-trivial for the purposes of calls
will be treated as though it were the following C type:
struct {
char c;
};
Before this patch was added, a structure parameter containing an empty
structure and
less than three floating-point members was passed through one
在 2023/5/24 下午2:45, Xi Ruoyao 写道:
On Wed, 2023-05-24 at 14:04 +0800, Lulu Cheng wrote:
An empty struct type that is not non-trivial for the purposes of calls
will be treated as though it were the following C type:
struct {
char c;
};
Before this patch was added, a structure parameter
在 2023/5/24 下午5:25, Xi Ruoyao 写道:
On Wed, 2023-05-24 at 16:47 +0800, Lulu Cheng wrote:
在 2023/5/24 下午2:45, Xi Ruoyao 写道:
On Wed, 2023-05-24 at 14:04 +0800, Lulu Cheng wrote:
An empty struct type that is not non-trivial for the purposes of
calls
will be treated as though it were the
> On Wed, 2023-05-24 at 14:45 +0800, Xi Ruoyao via Gcc-patches wrote:
> > On Wed, 2023-05-24 at 14:04 +0800, Lulu Cheng wrote:
> > > An empty struct type that is not non-trivial for the purposes of
> > > calls
> > > will be treated as though
在 2023/5/25 上午10:52, WANG Xuerui 写道:
On 2023/5/25 10:46, Lulu Cheng wrote:
在 2023/5/25 上午4:15, Jason Merrill 写道:
On Wed, May 24, 2023 at 5:00 AM Jonathan Wakely via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>> wrote:
On Wed, 24 May 2023 at 09:41, Xi Ruoyao wrote:
>
LGTM!
Thanks.
在 2022/9/13 下午11:32, Xi Ruoyao 写道:
Static PIE allows us to extend the ASLR to cover static executables and
it's not too difficult to support it. On GCC side, we just pass a group
of options to the linker, like other ports with static PIE support.
The real implementation of stati
The old stack detection was performed before the stack was dropped,
which would cause the detection tool to report a memory leak.
The current stack detection scheme is as follows:
'-fstack-clash-protection':
1. When the frame->total_size is smaller than the guard page size,
the stack is droppe
Co-Authored-By: qijingwen
include/ChangeLog:
* vtv-change-permission.h (defined):
(VTV_PAGE_SIZE): 16k pages under loongarch64.
libvtv/ChangeLog:
* configure.tgt: Add loongarch support.
---
include/vtv-change-permission.h | 2 ++
libvtv/configure.tgt| 3 +++
Co-Authored-By: Yang Yujie
libitm/ChangeLog:
* configure.tgt: Add loongarch support.
* config/loongarch/asm.h: New file.
* config/loongarch/sjlj.S: New file.
* config/loongarch/target.h: New file.
---
libitm/config/loongarch/asm.h| 54 +
libitm/c
This change may have to wait for the test results to determine whether
to merge.
在 2022/9/26 下午2:58, Xi Ruoyao 写道:
Currently our cache information from -mtune is not really used, pass it
to the optimizer so it will be really in-effect.
gcc/ChangeLog:
* config/loongarch/loongarch.cc
t I don't
see where this macro is used,
is there something wrong with my understanding?
在 2022/9/26 下午1:38, Xi Ruoyao 写道:
On Mon, 2022-09-26 at 10:00 +0800, Lulu Cheng wrote:
Co-Authored-By: qijingwen
include/ChangeLog:
* vtv-change-permission.h (defined):
(VTV_PA
r13-967 add ARRIF output format. However libvtv does not add support.
commit 6cf276ddf22066af780335cd0072d2c27aabe468
Author: David Malcolm
Date: Thu Jun 2 15:40:22 2022 -0400
diagnostics: add SARIF output format
libvtv/ChangeLog:
* testsui
Sorry, I will try to avoid this problem in the future.
在 2022/9/27 上午11:30, WANG Xuerui 写道:
On 2022/9/27 11:16, Lulu Cheng wrote:
r13-967 add ARRIF output format. However libvtv does not add
support.
"SARIF support was added in r13-967 but libvtv wasn't updated."
(Tip:
在 2022/9/27 上午11:16, Xi Ruoyao 写道:
On Mon, 2022-09-26 at 15:04 +0800, Lulu Cheng wrote:
This change may have to wait for the test results to determine whether
to merge.
With this patch and my other pending patches
- https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602172.html
- https
SARIF support was added in r13-967 but libvtv wasn't updated.
libvtv/ChangeLog:
* testsuite/lib/libvtv-dg.exp: Add load_gcc_lib of scansarif.exp.
---
libvtv/testsuite/lib/libvtv-dg.exp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libvtv/testsuite/lib/libvtv-dg.exp
b/lib
v1 - > v2:
1. When the macro __loongarch_lp64 is defined, the VTV_PAGE_SIZE is set to 64K.
2. In the vtv_malloc.cc file __vtv_malloc_init function, it does not check
whether VTV_PAGE_SIZE is equal to the system page size, if the macro
__loongarch_lp64 is defined.
All regression tests of l
在 2022/9/27 下午10:01, David Malcolm 写道:
On Tue, 2022-09-27 at 14:02 +0800, Lulu Cheng wrote:
SARIF support was added in r13-967 but libvtv wasn't updated.
Sorry about breaking this. The patch looks reasonable to me, FWIW,
assuming that it fixes the issue, of course!
Looks li
在 2022/9/26 上午10:05, Lulu Cheng 写道:
Co-Authored-By: Yang Yujie
libitm/ChangeLog:
* configure.tgt: Add loongarch support.
* config/loongarch/asm.h: New file.
* config/loongarch/sjlj.S: New file.
* config/loongarch/target.h: New file.
Pushed to r13-2910.
在 2022/9/27 下午7:44, Xi Ruoyao 写道:
On Tue, 2022-09-27 at 15:49 +0800, Lulu Cheng wrote:
#if defined (__CYGWIN__) || defined (__MINGW32__)
if (VTV_PAGE_SIZE != sysconf_SC_PAGE_SIZE())
+#elif defined (__loongarch_lp64)
+ /* I think that under the LoongArch 64-bit system, VTV_PAGE_SIZE is
I have no problem.
Thanks.
在 2022/9/24 下午8:47, Xi Ruoyao 写道:
I made a mistake defining fmin/fmax RTL patterns in r13-2085: I used
smin and smax in the definition mistakenly. This causes the optimizer
to perform constant folding as if fmin/fmax was "really" smin/smax
operations even with -fsign
Hi,
My colleague is testing the performance data of prefetch and prefetchx.
And will submit both supports together if there is no problem.
在 2022/9/25 下午7:25, Xi Ruoyao 写道:
The test pr106397.c fails on LoongArch because we don't have defined
prefetch instruction. We can silence the test for
在 2022/10/12 上午4:57, Caroline Tice 写道:
I think that if VTV_PAGE_SIZE is not set to the actual size being used
by the system, it could result in some unexpected failures. I
believe the right thing to do in this case, since the size may vary,
is to get the actual size being used by the system
Pushed to r13-3241
在 2022/9/27 下午10:01, David Malcolm 写道:
On Tue, 2022-09-27 at 14:02 +0800, Lulu Cheng wrote:
SARIF support was added in r13-967 but libvtv wasn't updated.
Sorry about breaking this. The patch looks reasonable to me, FWIW,
assuming that it fixes the issue, of c
Add a soft floating point condition to the register recovery part of the code.
libitm/ChangeLog:
* config/loongarch/sjlj.S: Add a soft floating point condition to the
register recovery part of the code.
---
libitm/config/loongarch/sjlj.S | 3 +++
1 file changed, 3 insertions(+)
From: chenglulu
gcc/ChangeLog:
* config/loongarch/loongarch.cc: Fix bug for
tmpdir-g++.dg-struct-layout-1/t033.
---
gcc/config/loongarch/loongarch.cc | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/gcc/config/loongarch/loongarch.cc
b/gcc/config/loo
From: chenglulu
gcc/ChangeLog:
* config/loongarch/loongarch.cc: Fix bug for
tmpdir-g++.dg-struct-layout-1/t033.
---
gcc/config/loongarch/loongarch.cc | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/gcc/config/loongarch/loongarch.cc
b/gcc/config/loong
Hi,all: This patch has been merged into the master branch. Thanks! Lulu
Cheng 在 2022/4/11 下午3:08, Lulu Cheng 写道:
From: chenglulu
gcc/ChangeLog:
* config/loongarch/loongarch.cc: Fix bug for
tmpdir-g++.dg-struct-layout-1/t033.
---
gcc/config/loongarch/loongarch.cc | 8
在 2022/10/13 下午2:44, Xi Ruoyao 写道:
On Thu, 2022-10-13 at 14:15 +0800, Levy wrote:
Hi RuoYao
It’s probably because loongarch64 doesn’t support
can_vec_perm_const_p(result_mode, op_mode, sel2, false)
I’m not sure whether if loongarch will support it or should I just
limit the test target for p
Looks good to me!
Thanks!
在 2022/10/12 下午10:23, Xi Ruoyao 写道:
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
在 2022/10/13 下午7:10, Richard Biener 写道:
On Thu, Oct 13, 2022 at 10:16 AM Lulu Cheng wrote:
在 2022/10/13 下午2:44, Xi Ruoyao 写道:
On Thu, 2022-10-13 at 14:15 +0800, Levy wrote:
Hi RuoYao
It’s probably because loongarch64 doesn’t support
can_vec_perm_const_p(result_mode, op_mode, sel2, false
1 - 100 of 452 matches
Mail list logo
