This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/38785] [6/7/8 Regression] huge performance regression on EEMBC bitmnp01
- From: "aldyh at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 01 Feb 2018 23:07:56 +0000
- Subject: [Bug tree-optimization/38785] [6/7/8 Regression] huge performance regression on EEMBC bitmnp01
- Auto-submitted: auto-generated
- References: <bug-38785-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aldyh at gcc dot gnu.org
--- Comment #48 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Is this still an issue?
int t(void);
void tt(int);
void
f (int i, long *a, long *b)
{
int sum = 0;
for (; --i >= 0; a++, b++)
{
b[i] = 0;
#define PART(I) if (t()) sum+=100+I;
PART (1);
PART (2);
PART (3);
PART (4);
PART (5);
PART (6);
tt (sum);
}
}
For --target=arc-elf, I've done:
./cc1 a.c -fdump-tree-all -quiet -I/tmp -O3 -mcpu=arc700
The inner loop looks like this:
bl @t;1
tst_s r0,r0
bl.d @t;1
add1.ne r13,r13,51 ;; r13 += 51 << 1 (which is 102)
tst_s r0,r0
add.ne r13,r13,103
bl @t;1
tst_s r0,r0
bl.d @t;1
add3.ne r13,r13,13 ;; r13 += 13 << 3 (which is 104)
tst_s r0,r0
add.ne r13,r13,105
...
...
I do not see any of the long sequences of integer constants on the stack, or
stack shuffling as was originally reported.
If I understand the first comment, i686 is presumably broken, but I see:
call t
testl %eax, %eax
je .L4
addl $101, %ebx
.L4:
call t
testl %eax, %eax
je .L5
addl $102, %ebx
.L5:
call t
testl %eax, %eax
je .L6
addl $103, %ebx
...
which doesn't look like long sequence of integers being pushed on the stack
either.
The PRE dump for arc700 doesn't show anything weird, or any combined ORed
values.
Has PRE changed and moved this bug around? Am I missing something?