[Bug bootstrap/115453] [15 regression] Noise from new dlopen, pthread configure checks since r15-1177-g75299e4fe50aa8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115453 YunQiang Su changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #13 from YunQiang Su --- It has been fixed.
[Bug target/111376] missed optimization of one bit test on MIPS32r1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376 --- Comment #18 from YunQiang Su --- https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654956.html
[Bug target/111376] missed optimization of one bit test on MIPS32r1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376 --- Comment #17 from YunQiang Su --- I send the patch here. So we may need some more test.
[Bug target/115500] RISC-V: Performance regression on 1bit test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115500 --- Comment #5 from YunQiang Su --- (In reply to Jeffrey A. Law from comment #4) > On the gcc-13, gcc-14 and the trunk I get this with -O2 on rv64gc: > > sllia5,a0,44 > blt a5,zero,.L3 > > > So ISTM that we must be doing something different. YunQiang, please make > sure to include the optimization options used when reporting a bug. > Thanks. I used -O2, and yes, slli/bltz is slower than srli/andi/bnez.
[Bug target/111376] missed optimization of one bit test on MIPS32r1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376 --- Comment #14 from YunQiang Su --- And it seems that the performance of SLL is related with the operand. Just iterate from 0 to 1e9: ``` 0b00 : b00: 000223c0sll a0,v0,0xf <-- the code is something wrong in normal code, we should access v0 here. v0 will be 100 or 1000. b04: 04810003bgeza0,b14 b08: nop b0c: 03e8jr ra b10: 240203e8li v0,1000 b14: 03e8jr ra b18: 24020064li v0,100 b1c: nop ``` is slower than ``` 0b00 : b00: 000223c0sll a0,a0,0xf b04: 04810003bgeza0,b14 b08: nop b0c: 03e8jr ra b10: 240203e8li v0,1000 b14: 03e8jr ra b18: 24020064li v0,100 b1c: nop ``` I have no idea how to make a trade off here.
[Bug target/111376] missed optimization of one bit test on MIPS32r1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376 --- Comment #13 from YunQiang Su --- I try to insert li $3, 500 li $5, 500 between SLL/BGEZ and LUI+AND/BNE. The later is still some faster on Loongson 3A4000. I notice something like this in 74K's software manual: The 74K core’s ALU is pipelined. Some ALU instructions complete the operation and bypass the results in this cycle. These instructions are referred to as single-cycle ops and they include all logical instructions (AND, ANDI, OR, ORI, XOR, XORI, LUI), some shift instructions (SLL sa<=8, SRL 31<=sa<=25), and some arithmetic instructions (ADD rt=0, ADDU rt=0, SLT, SLTI, SLTU, SLTIU, SEH, SEB, ZEH, ZEB). In addition, add instructions (ADD, ADDU, ADDI, ADDIU) complete the operation and bypass results to the ALU pipe in this cycle. I guess it means that if sa>8, SLL may be some slow. On Loongson 3A4000, the value seems to be 20/21. It may means that we should be care about for 64bit. Can you have a test on XBurst 1?
[Bug target/115500] RISC-V: Performance regression on 1bit test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115500 --- Comment #3 from YunQiang Su --- (In reply to Andrew Pinski from comment #2) > The big question is non zbs riscv arch matter any more? I have no idea. This is the Debian's porterbox, so I guess it meets the requirement of Debian's RV64 port baseline.
[Bug target/115500] RISC-V: Performance regression on 1bit test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115500 --- Comment #1 from YunQiang Su --- Talks about MIPS here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376
[Bug target/115500] New: RISC-V: Performance regression on 1bit test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115500
Bug ID: 115500
Summary: RISC-V: Performance regression on 1bit test
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: syq at gcc dot gnu.org
Target Milestone: ---
```x.c
#include
int f32(int);
int main() {
for(int i=0; i<1e9; i++) {
f32(i);
}
}
```
```f32.c
int f32(int x) {
if (x & 0x8)
return 100;
return 1000;
}
```
I test it on
isa : rv64imafdc_zicntr_zicsr_zifencei_zihpm
mmu : sv39
uarch : sifive,bullet0
mvendorid : 0x489
marchid : 0x8007
mimpid : 0x20181004
hart isa: rv64imafdc_zicntr_zicsr_zifencei_zihpm
With GCC12, the time cost is
real0m7.140s
user0m7.134s
sys 0m0.005s
With GCC13, the time cost is
real0m9.298s
user0m9.291s
sys 0m0.005s
The problem is about
0: 814dsrlia0,a0,0x13
2: 8905andia0,a0,1
4: e501bneza0,c <.L3>
vs
0: 02c51793sllia5,a0,0x2c
4: 0007c563bltza5,e <.L3>
[Bug target/111376] missed optimization of one bit test on MIPS32r1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376 YunQiang Su changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #11 from YunQiang Su --- For -Os, let's track it with this one https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115473
[Bug target/111376] missed optimization of one bit test on MIPS32r1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376 --- Comment #10 from YunQiang Su --- I have some performance test. sll+bgez is some slower than lui+and+beqz. On Loongson 3A4000, it is about 10%. So this "optimization" makes sense only for -Os.
[Bug target/115473] New: MIPS: -Os rtx_cost compare not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115473
Bug ID: 115473
Summary: MIPS: -Os rtx_cost compare not correct
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: syq at gcc dot gnu.org
Target Milestone: ---
f32(int a)
{
int p = (a & (1<<16));
if (p)
return f1();
else
return f2();
}
we can use
sll
bgez
to replace
li
and
beqz
[Bug target/111376] missed optimization of one bit test on MIPS32r1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376
--- Comment #9 from YunQiang Su ---
I see about condmove: it is broken since gcc14.
int
f32(int a)
{
int p = (a & (1<<16));
if (p)
return 100;
else
return 1000;
}
[Bug bootstrap/115416] [13/14/15 regression] Setting --includedir to a nonexistent directory causes a build error since r13-5490-g59e4c98173a79f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115416 --- Comment #7 from YunQiang Su --- Maybe this patch is better --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -560,11 +560,7 @@ LINKER_PLUGIN_API_H = $(srcdir)/../include/plugin-api.h # Default native SYSTEM_HEADER_DIR, to be overridden by targets. NATIVE_SYSTEM_HEADER_DIR = @NATIVE_SYSTEM_HEADER_DIR@ # Default cross SYSTEM_HEADER_DIR, to be overridden by targets. -ifeq (@includedir@,$(prefix)/include) - CROSS_SYSTEM_HEADER_DIR = @CROSS_SYSTEM_HEADER_DIR@ -else - CROSS_SYSTEM_HEADER_DIR = @includedir@ -endif +CROSS_SYSTEM_HEADER_DIR = @CROSS_SYSTEM_HEADER_DIR@ # autoconf sets SYSTEM_HEADER_DIR to one of the above. # Purge it of unnecessary internal relative paths @@ -581,7 +577,10 @@ BUILD_SYSTEM_HEADER_DIR = `echo @BUILD_SYSTEM_HEADER_DIR@ | sed -e :a -e 's,[^/] STMP_FIXINC = @STMP_FIXINC@ # Test to see whether exists in the system header files. -LIMITS_H_TEST = [ -f $(BUILD_SYSTEM_HEADER_DIR)/limits.h ] +LIMITS_H_TEST = headdir=$(BUILD_SYSTEM_HEADER_DIR) && \ + headdir_sys=`echo $$headdir | grep '/sys-include$$'` && \ + headdir_nosys=`echo $$headdir | sed 's/sys-include/include/'` && \ + [ -f $$headdir/limits.h -o -n $$headdir_sys -a -f "$$headdir_nosys/limits.h" ] # Directory for prefix to system directories, for # each of $(system_prefix)/usr/include, $(system_prefix)/usr/lib, etc. Background: For cross/no-with-sysroot, the BUILD_SYSTEM_HEADER_DIR value will be `$(gcc_tooldir)/sys-include`. Here, `sys-include` is used by `--with-headers` option. So let's detect $(gcc_tooldir)/include too.
[Bug bootstrap/115416] [13/14/15 regression] Setting --includedir to a nonexistent directory causes a build error since r13-5490-g59e4c98173a79f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115416 --- Comment #6 from YunQiang Su --- (In reply to Marcus Calhoun-Lopez from comment #5) > (In reply to YunQiang Su from comment #3) > > Since it doesn't exist, why use --includedir with it? > > /opt/local/include/gcc is where the header files will be installed after the > build, so there is no reason for it to exist before the build. > Normally, we build gcc for 1st stage with/without --includedir, and then build libc with 1st stage gcc, and install the libc into the destination. Then we build gcc stage2 with --includedir. Ohh, in fact that I am worrying that both you and I have a mistake: the --includedir may be used for host instead of target. Should we introduce a new build-time option? Background: I add this patch due to Debian's cross toolchain install headers into /usr//include instead of /usr//sys-include
[Bug bootstrap/115416] [13/14/15 regression] Setting --includedir to a nonexistent directory causes a build error since r13-5490-g59e4c98173a79f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115416 --- Comment #3 from YunQiang Su --- Since it doesn't exist, why use --includedir with it? Anyway, so, maybe we should detect the existence of this dir. Can you have a try of this patch? --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -560,10 +560,11 @@ LINKER_PLUGIN_API_H = $(srcdir)/../include/plugin-api.h # Default native SYSTEM_HEADER_DIR, to be overridden by targets. NATIVE_SYSTEM_HEADER_DIR = @NATIVE_SYSTEM_HEADER_DIR@ # Default cross SYSTEM_HEADER_DIR, to be overridden by targets. -ifeq (@includedir@,$(prefix)/include) - CROSS_SYSTEM_HEADER_DIR = @CROSS_SYSTEM_HEADER_DIR@ -else - CROSS_SYSTEM_HEADER_DIR = @includedir@ +CROSS_SYSTEM_HEADER_DIR = @CROSS_SYSTEM_HEADER_DIR@ +ifneq (@includedir@,$(prefix)/include) + ifneq (,$(wildcard @includedir@)) +CROSS_SYSTEM_HEADER_DIR = @includedir@ + endif endif
[Bug bootstrap/115416] [13/14/15 regression] Setting --includedir to a nonexistent directory causes a build error since r13-5490-g59e4c98173a79f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115416 --- Comment #2 from YunQiang Su --- Can you give me the configure command, so that I can have a test.
[Bug target/115393] New: MIPS: implemented _BitInt of C23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115393 Bug ID: 115393 Summary: MIPS: implemented _BitInt of C23 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: syq at gcc dot gnu.org Target Milestone: ---
[Bug target/111376] missed optimization of one bit test on MIPS32r1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376 --- Comment #7 from YunQiang Su --- Ohh, I need add "&&" before "!reload_completed". It seems work with -Os. can you give me you test code? I cannot figure out a non-workable condmove C code for it. With the constant less than 0x, ANDI+BEQ/BNE do be generated with -Os but not for -O2.
[Bug target/111376] missed optimization of one bit test on MIPS32r1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376
--- Comment #5 from YunQiang Su ---
I copy the RTL pattern from RISC-V, and it seems work
```
--- a/gcc/config/mips/mips.md
+++ b/gcc/config/mips/mips.md
@@ -6253,6 +6253,40 @@ (define_insn "*branch_bit_inverted"
}
[(set_attr "type" "branch")
(set_attr "branch_likely" "no")])
+
+(define_insn_and_split "*branch_on_bit"
+ [(set (pc)
+ (if_then_else
+ (match_operator 0 "equality_operator"
+ [(zero_extract:GPR (match_operand:GPR 2 "register_operand" "d")
+(const_int 1)
+(match_operand:GPR 3 "const_int_operand"))
+(const_int 0)])
+ (label_ref (match_operand 1))
+ (pc)))]
+ "!ISA_HAS_BBIT && !ISA_HAS_EXT_INS && !TARGET_MIPS16"
+ "#"
+ "!reload_completed"
+ [(set (match_dup 4)
+ (ashift:GPR (match_dup 2) (match_dup 3)))
+ (set (pc)
+ (if_then_else
+ (match_op_dup 0 [(match_dup 4) (const_int 0)])
+ (label_ref (match_operand 1))
+ (pc)))]
+{
+ int shift = GET_MODE_BITSIZE (mode) - 1 - INTVAL (operands[3]);
+ operands[3] = GEN_INT (shift);
+ operands[4] = gen_reg_rtx (mode);
+
+ if (GET_CODE (operands[0]) == EQ)
+operands[0] = gen_rtx_GE (mode, operands[4], const0_rtx);
+ else
+operands[0] = gen_rtx_LT (mode, operands[4], const0_rtx);
+}
+[(set_attr "type" "branch")])
+
+
```
[Bug target/111376] missed optimization of one bit test on MIPS32r1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376 --- Comment #4 from YunQiang Su --- Ohh, RISC-V has solved this problem in recent release. So we can just do similar work.
[Bug target/111376] missed optimization of one bit test on MIPS32r1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376
--- Comment #2 from YunQiang Su ---
(In reply to YunQiang Su from comment #1)
> RISC-V has this problem, too.
> Maybe we can try to combine it in `combine` pass, while it may be not easy.
> It may break some code like:
>
> ```
> int f1();
> int f2();
>
> int f(int a) {
> int p = (a & 0x8);
> if (p)
> return p;
> else
> return f2();
> }
> ```
>
> And in fact your patch also break it.
Ohh, this comment is not correct
[Bug target/111376] missed optimization of one bit test on MIPS32r1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376
--- Comment #1 from YunQiang Su ---
RISC-V has this problem, too.
Maybe we can try to combine it in `combine` pass, while it may be not easy.
It may break some code like:
```
int f1();
int f2();
int f(int a) {
int p = (a & 0x8);
if (p)
return p;
else
return f2();
}
```
And in fact your patch also break it.
[Bug target/115286] New: MIPS: mips16_rdhwr_one_only_stub::output_body clobber $3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115286 Bug ID: 115286 Summary: MIPS: mips16_rdhwr_one_only_stub::output_body clobber $3 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: syq at gcc dot gnu.org Target Milestone: --- It may be dangerous just like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84790
[Bug sanitizer/106136] gcc-12.1.1 - libsanitizer fails when compiled for MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106136 YunQiang Su changed: What|Removed |Added CC||syq at gcc dot gnu.org Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from YunQiang Su --- It has been fixed in newer version.
[Bug target/100760] [mips + msa] ICE: maximum number of generated reload insns per insn achieved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100760 YunQiang Su changed: What|Removed |Added Resolution|--- |FIXED CC||syq at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #3 from YunQiang Su --- Close it.
[Bug target/89245] [MIPS] v1 is assigned in jalr delay slot for later use at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89245 --- Comment #4 from YunQiang Su --- It has been fixed.
[Bug target/89245] [MIPS] v1 is assigned in jalr delay slot for later use at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89245 YunQiang Su changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||syq at gcc dot gnu.org --- Comment #3 from YunQiang Su --- It has been fixed.
[Bug middle-end/82051] [mips]mips emit different results when compiling union var using -O0/-O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82051 YunQiang Su changed: What|Removed |Added Resolution|--- |INVALID CC||syq at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #4 from YunQiang Su --- So, we believes that it is invalid.
[Bug target/84790] Miscompilation for MIPS16 with -fpic and -Os or -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84790 YunQiang Su changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from YunQiang Su --- Fixed by https://gcc.gnu.org/g:915440eed21de367cb41857afb5273aff5bcb737
[Bug target/84790] Miscompilation for MIPS16 with -fpic and -Os or -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84790 --- Comment #14 from YunQiang Su --- Ohh, sorry for my misunderstanding. Your patch is correct. The real problem is that, $3 is used by `mips_output_function_prologue`, which is the final for output asm source code, and thus the IRA pass cannot be aware that $3 is used. So we have to emit some clobbers before IRA. We have 2 choice: 1. Your choice, aka emit clobbers just before the the call function 2. the entrance every function that need to use GP @@ -3329,6 +3331,8 @@ mips16_gp_pseudo_reg (void) rtx set = gen_load_const_gp (cfun->machine->mips16_gp_pseudo_rtx); rtx_insn *insn = emit_insn_after (set, scan); INSN_LOCATION (insn) = 0; + emit_clobber (MIPS16_PIC_TEMP); + emit_clobber (MIPS_PROLOGUE_TEMP (Pmode)); pop_topmost_sequence (); }
[Bug target/84790] Miscompilation for MIPS16 with -fpic and -Os or -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84790
--- Comment #12 from YunQiang Su ---
You are right: the decision to use $6 is too late.
So let's force to use it in expand pass.
```
diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc
index b63d40a357b..84ff29cd62b 100644
--- a/gcc/config/mips/mips.cc
+++ b/gcc/config/mips/mips.cc
@@ -3318,7 +3318,11 @@ mips16_gp_pseudo_reg (void)
{
rtx_insn *scan;
- cfun->machine->mips16_gp_pseudo_rtx = gen_reg_rtx (Pmode);
+ if (TARGET_USE_GOT)
+ cfun->machine->mips16_gp_pseudo_rtx
+ = gen_rtx_REG (Pmode, POST_CALL_TMP_REG);
+ else
+ cfun->machine->mips16_gp_pseudo_rtx = gen_reg_rtx (Pmode);
push_topmost_sequence ();
```
[Bug target/84790] Miscompilation for MIPS16 with -fpic and -Os or -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84790
--- Comment #11 from YunQiang Su ---
(In reply to YunQiang Su from comment #8)
> Ohh, In fact we should use $28 if TARGET_USE_GOT.
>
> Can you help to test this patch?
>
> ```
> diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc
> index b63d40a357b..fe8641d3916 100644
> --- a/gcc/config/mips/mips.cc
> +++ b/gcc/config/mips/mips.cc
> @@ -3342,7 +3342,7 @@ mips16_gp_pseudo_reg (void)
> rtx
> mips_pic_base_register (rtx temp)
> {
> - if (MIPS16_GP_LOADS ||!TARGET_MIPS16)
> + if (MIPS16_GP_LOADS || TARGET_USE_GOT ||!TARGET_MIPS16)
> return pic_offset_table_rtx;
>
>if (currently_expanding_to_rtl)
> ```
This patch can trigger some ICE
[Bug target/84790] Miscompilation for MIPS16 with -fpic and -Os or -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84790 --- Comment #9 from YunQiang Su --- (In reply to Matthias Schiffer from comment #7) > (In reply to YunQiang Su from comment #6) > > The attached patch cannot work now. > > > > It is not correct, and it happened work due to good luck that the same > > register was allocated for these 2 instructions. > > I believe this is not the case. The gp init sequence is inserted very late, > and no register allocation is involved - the use of registers $2 and $3 is > hardcoded: Here $6(a2) is hardcoded, while $3(v1) is not.
[Bug target/84790] Miscompilation for MIPS16 with -fpic and -Os or -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84790
--- Comment #8 from YunQiang Su ---
Ohh, In fact we should use $28 if TARGET_USE_GOT.
Can you help to test this patch?
```
diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc
index b63d40a357b..fe8641d3916 100644
--- a/gcc/config/mips/mips.cc
+++ b/gcc/config/mips/mips.cc
@@ -3342,7 +3342,7 @@ mips16_gp_pseudo_reg (void)
rtx
mips_pic_base_register (rtx temp)
{
- if (MIPS16_GP_LOADS ||!TARGET_MIPS16)
+ if (MIPS16_GP_LOADS || TARGET_USE_GOT ||!TARGET_MIPS16)
return pic_offset_table_rtx;
if (currently_expanding_to_rtl)
```
[Bug target/84790] Miscompilation for MIPS16 with -fpic and -Os or -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84790 --- Comment #6 from YunQiang Su --- The attached patch cannot work now. It is not correct, and it happened work due to good luck that the same register was allocated for these 2 instructions.
[Bug target/84790] Miscompilation for MIPS16 with -fpic and -Os or -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84790 YunQiang Su changed: What|Removed |Added Last reconfirmed||2024-05-22 CC||syq at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #5 from YunQiang Su --- Assign it to me.
[Bug target/113932] [meta-bug] Targets which should be ported to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932 Bug 113932 depends on bug 113955, which changed state. Bug 113955 Summary: Finish LRA transition for mips by removing -mlra https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113955 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/113955] Finish LRA transition for mips by removing -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113955 YunQiang Su changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from YunQiang Su --- Fixed by: https://gcc.gnu.org/g:d3b4ba120ce3b743838c3545a24554989955722a
[Bug target/114976] New: MIPS64: get double high part can use mfhc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114976
Bug ID: 114976
Summary: MIPS64: get double high part can use mfhc1
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: syq at gcc dot gnu.org
Target Milestone: ---
```
unsigned int
__mips_mfhc1 (double x)
{
unsigned int ret;
union {
unsigned long long i;
double d;
} xx;
xx.d=x;
ret = xx.i>>32;
return ret;
}
```
For R2+, we can just use `mfhc1`, while currently the output is
```
dmfc1 $2,$f12
jr $31
dsra$2,$2,32
```
[Bug middle-end/113180] MIPS: bitops on an long long struct uses ins instead dins (or with -mstrict-align on aarch64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113180 --- Comment #3 from YunQiang Su --- The argument `to` of `expand_assignment` differs between `strict-align` and `no-strict-align`. `debug_tree` states that the `strict-align` one has a `MEMREF` RTL, while `no-strict-align` has a `reg` one. Any idea when the RTL is generated from STMT?
[Bug middle-end/113179] [11/12/13/14/15 Regression] MIPS: INS is used for long long, before SLL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113179 --- Comment #6 from YunQiang Su --- With some test on some CPUs, in fact, the lacking of `sll` won't make troubles to us. It seems that most of MIPS64 CPUs can process it well as expected.
[Bug middle-end/113179] [11/12/13/14/15 Regression] MIPS: INS is used for long long, before SLL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113179 YunQiang Su changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from YunQiang Su --- Fixed in GCC 15. Should we backport it to the previous versions?
[Bug middle-end/113179] [11/12/13/14/15 Regression] MIPS: INS is used for long long, before SLL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113179 --- Comment #3 from YunQiang Su --- 36088299955f95ab58a5758cba2f29b84c8fbfbc is the first bad commit commit 36088299955f95ab58a5758cba2f29b84c8fbfbc Author: Richard Biener Date: Wed Jun 29 07:17:57 2016 + match.pd ((T)(T2)x -> (T)x): Remove restriction on final precision not matching mode precision. 2016-07-29 Richard Biener * match.pd ((T)(T2)x -> (T)x): Remove restriction on final precision not matching mode precision. From-SVN: r237838 gcc/ChangeLog | 5 + gcc/match.pd | 11 +++ 2 files changed, 8 insertions(+), 8 deletions(-)
[Bug target/114344] New: [arm/mips] __alignof__ report a member packed struct as 1, while normal load/store instruction is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114344
Bug ID: 114344
Summary: [arm/mips] __alignof__ report a member packed struct
as 1, while normal load/store instruction is used
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: syq at gcc dot gnu.org
Target Milestone: ---
#include
volatile
struct s
{
char c[4];
int i;
long long l;
float f;
double d;
} __attribute__ ((packed)) s;
int main() {
s.i = 0x12345678;
printf ("%zd\n", __alignof__ (s.i));
}
For this code, `1` is printed as the align of s.i. While on MIPS and ARM,
normal instructions are emitted.
$ mipsel-linux-gnu-gcc -Wall -mabi=32 -c -O3 xx.c -mips32r2
$ objdump -d xx.o
...
34: ac620004sw v0,4(v1)
...
If `__alignof__ (s.i)` reports correctly, `swl/swr` should be used instead of
`sw`.
And for
$ mipsel-linux-gnu-gcc -c -O3 xx.c -mips32r6 -mno-unaligned-access
$ arm-linux-gnueabihf-gcc -c -O3 xx.c -mno-unaligned-access
4 store_byte instruction should be used, while in fact, `sw/str` is used here.
[Bug target/111555] [AArch64] __ARM_FEATURE_UNALIGNED should be undefined with -mstrict-align
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111555 YunQiang Su changed: What|Removed |Added CC||syq at gcc dot gnu.org --- Comment #2 from YunQiang Su --- `-mno-unaligned-access` is also supported by MIPSr6. I guess we should add a more generic macro for this case? Is __UNALIGN_ACCESS_DISABLED__ OK? For AArch64, clang supports `-mno-unaligned-access`, while gcc doesn't, should we add it as an alias of -mstrict-align?
[Bug target/113955] Finish LRA transition for mips by removing -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113955 --- Comment #3 from YunQiang Su --- -mlra has been set to default since it was added (2014). So, It is ok for us to remove it.
[Bug target/113955] Finish LRA transition for mips by removing -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113955 --- Comment #2 from YunQiang Su --- Maybe we can set it as the release target of GCC 15.
[Bug target/113655] Cross compiling to mips64-elf fails because "MIPS_EXPLICIT_RELOCS was not declared" after r14-8386-g58af788d1d0825
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113655 YunQiang Su changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from YunQiang Su --- I think that this problem has been resolved. If no, you can just reopen this report.
[Bug target/113655] Cross compiling to mips64-elf fails because "MIPS_EXPLICIT_RELOCS was not declared" after r14-8386-g58af788d1d0825
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113655 --- Comment #1 from YunQiang Su --- Thank for your report. It's due to a typo I will fix it now.
[Bug middle-end/113354] [14 Regression] : unable to find a register to spill on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113354 YunQiang Su changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from YunQiang Su --- Thanks. I can confirm that this issue has be fixed.
[Bug middle-end/113354] Regression/14: unable to find a register to spill on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113354
--- Comment #1 from YunQiang Su ---
In file included from
../../../../../libstdc++-v3/src/c++17/floating_from_chars.cc:86:
../../../../../libstdc++-v3/src/c++17/fast_float/fast_float.h: In function
‘std::from_chars_result {anonymous}::fast_float::from_chars_advanced(const c
har*, const char*, T&, parse_options) [with T = double]’:
../../../../../libstdc++-v3/src/c++17/fast_float/fast_float.h:3039:1: error:
unable to find a register to spill
3039 | }
| ^
../../../../../libstdc++-v3/src/c++17/fast_float/fast_float.h:3039:1: error:
this is the insn:
(insn 3578 7721 7722 263 (parallel [
(set (reg:SI 3353)
(plus:SI (mult:SI (reg:SI 3185 [orig:2219 _914+4 ] [2219])
(reg:SI 2175 [ _280+4 ]))
(reg:SI 3354)))
(clobber (reg:SI 3186 [3073]))
(clobber (reg:SI 3074))
])
"../../../../../libstdc++-v3/src/c++17/fast_float/fast_float.h":248:26 42
{*mul_acc_si}
(expr_list:REG_UNUSED (reg:SI 3074)
(expr_list:REG_UNUSED (reg:SI 3186 [3073])
(expr_list:REG_DEAD (reg:SI 3354)
(expr_list:REG_DEAD (reg:SI 3185 [orig:2219 _914+4 ] [2219])
(nil))
during RTL pass: reload
../../../../../libstdc++-v3/src/c++17/fast_float/fast_float.h:3039:1: internal
compiler error: in lra_split_hard_reg_for, at lra-assigns.cc:1862
0x7cf140 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/rtl-error.cc:108
0x10184c5
lra_split_hard_reg_for()
../../gcc/lra-assigns.cc:1862
0x1012405
lra(_IO_FILE*, int)
../../gcc/lra.cc:2518
0xfc76df do_reload
../../gcc/ira.cc:5973
0xfc76df execute
../../gcc/ira.cc:6161
[Bug middle-end/113354] New: Regression/14: unable to find a register to spill on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113354
Bug ID: 113354
Summary: Regression/14: unable to find a register to spill on
mips
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: syq at gcc dot gnu.org
Target Milestone: ---
../../../libgfortran/generated/matmul_i4.c: In function ‘matmul_i4’:
../../../libgfortran/generated/matmul_i4.c:3006:1: error: unable to find a
register to spill
3006 | }
| ^
../../../libgfortran/generated/matmul_i4.c:3006:1: error: this is the insn:
(insn 1643 7974 7975 184 (parallel [
(set (reg/v:SI 2999 [orig:435 f34 ] [435])
(plus:SI (mult:SI (reg:SI 286 [ _332 ])
(reg:SI 289 [ _342 ]))
(reg/v:SI 3000 [orig:435 f34 ] [435])))
(clobber (reg:SI 2791 [2407]))
(clobber (reg:SI 2408))
]) "../../../libgfortran/generated/matmul_i4.c":2820:14 42
{*mul_acc_si}
(expr_list:REG_UNUSED (reg:SI 2408)
(expr_list:REG_UNUSED (reg:SI 2791 [2407])
(expr_list:REG_DEAD (reg/v:SI 3000 [orig:435 f34 ] [435])
(expr_list:REG_DEAD (reg:SI 289 [ _342 ])
(nil))
during RTL pass: reload
../../../libgfortran/generated/matmul_i4.c:3006:1: internal compiler error: in
lra_split_hard_reg_for, at lra-assigns.cc:1862
[Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled int value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914 YunQiang Su changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #26 from YunQiang Su --- Since we have 2 fixes both fixed this problem. Let's close it. Should we back port it to gcc13/gcc12?
[Bug tree-optimization/113227] Maybe optimization (a>0) && (b>0) with or&<0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113227 YunQiang Su changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from YunQiang Su --- It is not correct.
[Bug tree-optimization/113227] Maybe optimization (a>0) && (b>0) with or&<0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113227 --- Comment #1 from YunQiang Su --- Sorry for noise. This proposal is wrong.
[Bug tree-optimization/113227] New: Maybe optimization (a>0) && (b>0) with or&<0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113227
Bug ID: 113227
Summary: Maybe optimization (a>0) && (b>0) with or&<0
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: syq at gcc dot gnu.org
Target Milestone: ---
_Bool f (int a, int b) {
return a > 0 && b > 0;
}
_Bool f (int a, int b)
{
_Bool _1;
_Bool _6;
_Bool _7;
[local count: 1073741824]:
_6 = b_3(D) > 0;
_7 = a_2(D) > 0;
_1 = _6 & _7;
return _1;
}
maybe we can do it like this?
_Bool f (int a, int b)
{
int _1 = (a | b);
return ((_1) > 0);
}
[Bug rtl-optimization/113185] New: bad performance on big-endian&64bit port for struct 16 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113185
Bug ID: 113185
Summary: bad performance on big-endian&64bit port for struct 16
16
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: syq at gcc dot gnu.org
Target Milestone: ---
```
struct xx {
int a:16;
int b:16;
};
struct xx xx (struct xx a, long long b) {
a.b = b;
return a;
}
```
On little-endian&64, only 1 or 2 instructions are used, such as
on AARCH64el:
```
bfi w0, w1, 16, 16
ret
```
On MIPS64el
```
move$2,$4
sll $5,$5,0
jr $31
ins $2,$5,16,16
```
While for 64EB
```
.cfi_startproc
sub sp, sp, #16
.cfi_def_cfa_offset 16
str x0, [sp, 8]
strhw1, [sp, 10]
ldr w0, [sp, 8]
add sp, sp, 16
.cfi_def_cfa_offset 0
lsl x0, x0, 32
ret
.cfi_endproc
```
```
daddiu $sp,$sp,-16
sd $4,0($sp)
sh $5,2($sp)
lw $2,0($sp)
daddiu $sp,$sp,16
jr $31
dsll$2,$2,32
```
[Bug target/113180] New: MIPS: bitops on an long long struct uses ins instead dins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113180
Bug ID: 113180
Summary: MIPS: bitops on an long long struct uses ins instead
dins
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: syq at gcc dot gnu.org
Target Milestone: ---
```
struct yy {
int x:32;
int a:12;
int b:12;
int c:4;
int d:4;
};
struct yy xx (struct yy a, long long b) {
a.d = b;
return a;
}
```
One DINS is enough for this ops, while currently the result is:
```
dsra$2,$4,32
daddiu $sp,$sp,-32
ins $2,$5,28,4
sd $4,16($sp)
sw $2,20($sp)
ld $3,16($sp)
move$2,$0
sll $4,$3,0
dext$4,$4,0,32
dins$2,$4,0,32
dsrl$3,$3,32
dins$2,$3,32,32
jr $31
daddiu $sp,$sp,32
```
[Bug target/113179] New: MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113179
Bug ID: 113179
Summary: MIPS
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: syq at gcc dot gnu.org
Target Milestone: ---
```
struct xx {
int a:4;
int b:24;
int c:3;
int d:1;
};
void xx (struct xx *a, long long b) {
a->d = b;
}
```
When this code is built on -mabi=64, it generates asm like this:
```
lw $2,0($4)
ins $2,$5,31,1
jr $31
sw $2,0($4)
```
Since the argument B is `long long`, we cannot be sure that it is well
sign-extended, while INS asks for it:
```
If either GPR rs or GPR rt does not contain sign-extended 32-bit values (bits
63..31 equal), then the result of the operation is UNPREDICTABLE.
```
[Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled int value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914 --- Comment #23 from YunQiang Su --- I guess, we should drop TRULY_NOOP_TRUNCATION_MODES_P and TARGET_MODE_REP_EXTENDED for MIPS. In fact, it will only effect MIPS64 SI->DI. Then it may reduce the maintain workload for MIPS64. Let's have a try and run some benchmark.
[Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled int value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914 --- Comment #22 from YunQiang Su --- Any way, we should split the assert to another patch. I will try to find all the wrongly used TRULY_NOOP_TRUNCATION_MODES_P.
[Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled int value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914 --- Comment #21 from YunQiang Su --- Sorry, Roger. Your patch is correct. I misunderstood it.
[Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled int value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914 --- Comment #20 from YunQiang Su --- This patch has 2 problems: 1. We may need some more steps to add gcc_assert (outprec < inprec) Now, I met some ICE with it. 2. It doesn't solve the this problem: In combine.cc, jump_insn eats truncate and sign_extend. In fact that is the real problem: How to tell combine.cc: don't eat it; this truncate/sign_extend is really needed by us.
[Bug driver/112759] [13/14 regression] mips -march=native detection broken with gcc 13+ since r13-3178-g66c48be23e0fa5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112759 YunQiang Su changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from YunQiang Su --- It should be fixed now, and back ported to gcc13. And we may should add some more detections: 1. hwcap 2. getauxval(AT_PLATFORM) 3. more cpuinfo parsing
[Bug driver/112759] [13/14 regression] mips -march=native detection broken with gcc 13+ since r13-3178-g66c48be23e0fa5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112759
--- Comment #6 from YunQiang Su ---
ohh, it should be concat(" ", NULL);
[Bug driver/112759] [13/14 regression] mips -march=native detection broken with gcc 13+ since r13-3178-g66c48be23e0fa5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112759
--- Comment #5 from YunQiang Su ---
It's my fault.
I misunderstanding `reconcat`:
if `optr` is NULL, it cannot work as the `s1` at the sametime.
If so, the return string will be empty.
So, let's define and initial ret like this:
char *ret = concat(" ");
Any idea?
[Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled int value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #16 from YunQiang Su ---
(In reply to Roger Sayle from comment #15)
> Is MIPS64 actually a TRULY_NOOP_TRUNCATION_TARGET? If SImode is implicitly
> assumed to be (sign?) extended, then an arbitrary DImode value/register
> can't be used as an SImode value without appropriately setting/clearing the
> upper bits.
> i.e. thus this integer truncation isn't a no-op.
>
in gcc/config/mips/mips.cc, there are lines:
static bool
mips_truly_noop_truncation (poly_uint64 outprec, poly_uint64 inprec)
{
return !TARGET_64BIT || inprec <= 32 || outprec > 32;
}
So for mips_truly_noop_truncation(64, 32), it is true, aka we can convert
32bit value to 64bit value without any insn.
This setting is based on that most (if not all) word (32bit) operation insns
are all sign-extend.
For example, when we run these instructions on a MIPS64 CPU
li $a1, 0x7fff
add $a3, $a1, $a1
The result of $a3 will be:
0x fffe
And for theses instructions:
li $a1, 0x7fff
dadd $a3, $a1, $a1 # note, add -> dadd
Then the content of $a3 will be:
0x fffe
And MIPS has the single instruction for: branch less than zero, for both
MIPS32, MIPS64.
Let me explain example 1:
if the code is running on a 32bit CPU, the result of $a3 will be
0xfffe, which is -2.
if the code is running on a 64bit CPU, since the result of $a3 will be
sign-extend to 0x fffe,
it is still -2.
That's how MIPS make 32bit binaries run smoothly on a 64bit CPU
without any mode switch.
> I suspect that the underlying problem is that the backend is relying on
> implicit invariants, not explicitly represented in the RTL, and then
> surprised when valid RTL transformations don't preserve those
> invariants/assumptions.
>
> I wonder why the zero_extract followed by sign_extend example mentioned in
> https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626137.html isn't
> already being considered as a try_combine candidate, allowing the backend to
> simply recognize or split it. I'll investigate.
Thanks.
[Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled int value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #14 from YunQiang Su ---
New patch:
diff --git a/gcc/expmed.cc b/gcc/expmed.cc
index fbd4ce2d42f..66d45da67df 100644
--- a/gcc/expmed.cc
+++ b/gcc/expmed.cc
@@ -850,6 +850,7 @@ store_bit_field_1 (rtx str_rtx, poly_uint64 bitsize,
poly_uint64 bitnum,
since that case is valid for any mode. The following cases are only
valid for integral modes. */
opt_scalar_int_mode op0_mode = int_mode_for_mode (GET_MODE (op0));
+ opt_scalar_int_mode str_mode = int_mode_for_mode (GET_MODE (str_rtx));
scalar_int_mode imode;
if (!op0_mode.exists () || imode != GET_MODE (op0))
{
@@ -881,8 +882,15 @@ store_bit_field_1 (rtx str_rtx, poly_uint64 bitsize,
poly_uint64 bitnum,
op0 = gen_lowpart (op0_mode.require (), op0);
}
- return store_integral_bit_field (op0, op0_mode, ibitsize, ibitnum,
- bitregion_start, bitregion_end,
+ bool use_str_mode = false;
+ if (GET_MODE_CLASS(GET_MODE (str_rtx)) == MODE_INT
+ && GET_MODE_CLASS(GET_MODE (op0)) == MODE_INT
+ && known_gt (GET_MODE_SIZE(GET_MODE(op0)),
GET_MODE_SIZE(GET_MODE(str_rtx
+use_str_mode = true;
+
+ return store_integral_bit_field (use_str_mode ? str_rtx : op0,
+ use_str_mode ? str_mode : op0_mode,
+ ibitsize, ibitnum, bitregion_start,
bitregion_end,
fieldmode, value, reverse, fallback_p);
}
[Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled int value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #13 from YunQiang Su ---
This tiny patch works will this small test case by replace with dins to ins.
I have no idea whether it will have any side effects.
Any idea?
diff --git a/gcc/expmed.cc b/gcc/expmed.cc
index fbd4ce2d42f..37f90912122 100644
--- a/gcc/expmed.cc
+++ b/gcc/expmed.cc
@@ -849,7 +849,7 @@ store_bit_field_1 (rtx str_rtx, poly_uint64 bitsize,
poly_uint64 bitnum,
if we aren't. This must come after the entire register case above,
since that case is valid for any mode. The following cases are only
valid for integral modes. */
- opt_scalar_int_mode op0_mode = int_mode_for_mode (GET_MODE (op0));
+ opt_scalar_int_mode op0_mode = int_mode_for_mode (GET_MODE (str_rtx));
scalar_int_mode imode;
if (!op0_mode.exists () || imode != GET_MODE (op0))
{
[Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled int value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #8 from YunQiang Su ---
(In reply to Andrew Pinski from comment #7)
> The initial RTL has a signed extend in there:
>
>
> (insn 20 19 23 2 (set (reg/v:DI 200 [ val+-4 ])
> (sign_extend:DI (subreg:SI (reg/v:DI 200 [ val+-4 ]) 4)))
> "/app/example.cpp":7:29 -1
> (nil))
> (jump_insn 23 20 24 2 (set (pc)
> (if_then_else (le (subreg/s/u:SI (reg/v:DI 200 [ val+-4 ]) 4)
> (const_int 0 [0]))
> (label_ref 32)
> (pc))) "/app/example.cpp":8:5 -1
> (int_list:REG_BR_PROB 440234148 (nil))
> -> 32)
>
>
> Before combine also looks fine:
> (insn 20 19 23 2 (set (reg/v:DI 200 [ val+-4 ])
> (sign_extend:DI (subreg:SI (reg/v:DI 200 [ val+-4 ]) 4)))
> "/app/example.cpp":7:29 235 {extendsidi2}
> (nil))
Yes. I noticed it. while in mips.md, extendsidi2 is expanded to no
instructions at all.
```
;; Extension insns.
;; Those for integer source operand are ordered widest source type first.
;; When TARGET_64BIT, all SImode integer and accumulator registers
;; should already be in sign-extended form (see TARGET_TRULY_NOOP_TRUNCATION
;; and truncdisi2). We can therefore get rid of register->register
;; instructions if we constrain the source to be in the same register as
;; the destination.
;;
;; Only the pre-reload scheduler sees the type of the register alternatives;
;; we split them into nothing before the post-reload scheduler runs.
;; These alternatives therefore have type "move" in order to reflect
;; what happens if the two pre-reload operands cannot be tied, and are
;; instead allocated two separate GPRs. We don't distinguish between
;; the GPR and LO cases because we don't usually know during pre-reload
;; scheduling whether an operand will be LO or not.
(define_insn_and_split "extendsidi2"
[(set (match_operand:DI 0 "register_operand" "=d,l,d")
(sign_extend:DI (match_operand:SI 1 "nonimmediate_operand" "0,0,m")))]
"TARGET_64BIT"
"@
#
#
lw\t%0,%1"
"&& reload_completed && register_operand (operands[1], VOIDmode)"
[(const_int 0)]
{
emit_note (NOTE_INSN_DELETED);
DONE;
}
[(set_attr "move_type" "move,move,load")
(set_attr "mode" "DI")])
```
[Bug sanitizer/105614] mips64: sanitizer_platform_limits_linux.cpp:75:38: error: static assertion failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105614 YunQiang Su changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #23 from YunQiang Su --- Fixed since e08835fd3a4a6559b79c26db9b18df0e838d943e
[Bug sanitizer/105614] mips64: sanitizer_platform_limits_linux.cpp:75:38: error: static assertion failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105614 YunQiang Su changed: What|Removed |Added CC||syq at gcc dot gnu.org --- Comment #21 from YunQiang Su --- I believe this problem has been addressed since e08835fd3a4a6559b79c26db9b18df0e838d943e Can you have a test it?
[Bug target/104914] [MIPS] wrong comparison with scrabbled int value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914 --- Comment #6 from YunQiang Su --- In RTL (xx.c.256r.expand), there is (insn 10 9 11 2 (set (zero_extract:DI (reg/v:DI 200 [ val ]) (const_int 8 [0x8]) (const_int 0 [0])) (subreg:DI (reg:QI 202) 0)) "xx.c":4:29 -1 (nil)) Maybe, it wrong as the mode cannot show the real length of val.
[Bug target/104914] [MIPS] wrong comparison with scrabbled int value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914 --- Comment #5 from YunQiang Su --- Another possible fix is to emit a SLL for extendsidi2, but I am worrying about it may break something else.
[Bug target/104914] [MIPS] wrong comparison with scrabbled int value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914 --- Comment #3 from YunQiang Su --- Ohhh, I think that the real problem is that: why DINS is used instead of INS when work with an INT?
[Bug target/104914] [MIPS] wrong comparison with scrabbled int value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914 YunQiang Su changed: What|Removed |Added CC||syq at gcc dot gnu.org --- Comment #2 from YunQiang Su --- In fact, gcc-11 works with `short', for which, seh is used to sign extending.
[Bug target/109435] overaligned structs are not passed correctly for mips64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109435 YunQiang Su changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||syq at gcc dot gnu.org --- Comment #5 from YunQiang Su --- Fixed by commit: https://gcc.gnu.org/g:e20abdb749d0c0c8552da998ff8ec139b830f5eb
