[Bug tree-optimization/38785] [6/7/8 Regression] huge performance regression on EEMBC bitmnp01

["aldyh at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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?