https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111724
Bug ID: 111724
Summary: [Regression] Missed optimizations probably because of
too early arithmetic optimization
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: 652023330028 at smail dot nju.edu.cn
Target Milestone: ---
Hello, we found some optimizations (probably because of too early arithmetic
optimization) that GCC may have missed. We would greatly appreicate if you can
take a look and let us know what you think.
Given the following code:
https://godbolt.org/z/8EW8fx78K
int n;
void func(int w, int a, int b){
for(int i=0;i<w;i++){
n += (a+a)+(b+b);
b += b;
}
}
`a+a` is a loop invariant. But gcc-trunk -O3:
func(int, int, int):
push {r4, lr}
subs lr, r0, #0
ble .L1
movw r4, #:lower16:.LANCHOR0
movt r4, #:upper16:.LANCHOR0
mov ip, #0
ldr r0, [r4]
.L3:
adds r3, r1, r2
add ip, ip, #1
lsls r2, r2, #1
cmp lr, ip
add r0, r0, r3, lsl #1
bne .L3
str r0, [r4]
>From original(tree):
(void) (n = (a + b) * 2 + n) >>>>>;
This leads to:
_1 = a_11(D) + b_18;
_2 = _1 * 2;
_4 = _2 + n_lsm.4_7;
So, it looks like the missed LICM is due to too early arithmetic optimization.
On gcc-6.4, it works as expected.
We found that this also affects other optimizations, such as common
subexpression elimination. We can provide examples if required.
Thank you very much for your time and effort! We look forward to hearing from
you.
