IA-64 speculation patches have bad impact on ARM

[Daniel Jacobowitz]

Hi Maxim and Vlad,

I just tracked an ICE while building glibc for ARM to this patch,
which introduced --param max-sched-extend-regions-iters with a default
of two:

  http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00998.html

The testcase is attached; an arm-linux-gnueabi compiler should be able to
reproduce it with -p -O2.  The failure is inability to find two consecutive
registers to hold a DImode value.  The cause is roughly like this:

  DImode add;
  if (({complicated asm with many local register variables}))
    return 0;

The register variables get lifted out of the if statement and moved before
the add, thus occupying basically all available hard registers.

If it were just that, I might try to cobble around it in glibc.  But there's
actually another layer:

  if (DImode compare)
    {
       DImode add;
       if (({complicated asm with many local register variables}))
         return 0;
       ...
    }

The register variables and their initializations get hoisted all the way out
of the first if.  On ia64, with a million execution units to spare and a
fat pipeline, this may make sense.  On targets with a simpler execution
model, though, it's pretty awful.  If the condition (which we have no
information on the likelihood of) is false, we've added lots of cycles for
no gain.  It's not like the scheduler was filling holes; the initializations
were scheduled as early as possible because they had no dependencies.

With the parameter turned back down to one, the testcase compiles, and the
code looks sensible again.  No, I wasn't able to work out why profiling was
necessary to trigger this problem; I suspect it makes some register
unavailable, but I'm not sure which.  I didn't look into that further.

What's your opinion?  We could easily change the default of the parameter
for ARM, but I assume there are other affected targets.  I don't know if we
need the extended region scheduling to be smarter, or if it should simply be
turned off for some targets.

-- 
Daniel Jacobowitz
CodeSourcery
-------------- next part --------------
A non-text attachment was scrubbed...
Name: final.c
Type: text/x-csrc
Size: 1031 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20060526/54b21e6f/attachment.bin>