== This week ==

* More on -fsched-pressure.  Testing on POWER7 showed a degenerate case
  that I'd failed to handle well.  Fixed that.  Saw that part of the
  problem on POWER7 was that IRA was using a combination of GENERAL_REGS
  and CR_REGS as a single pressure class, so there appeared to be 39
  registers available for storing integers.  Fixed (or worked around) that.

  Tweaked a few other things too.  The only denbench result that I
  wasn't happy with was RSA, where both forms of -fsched-pressure are
  significantly worse than -fno-sched-pressure.  Tracked down the cause
  of that.  We had a block BB1:

       A: (set (reg:DI X) Y)
       B: (clobber (reg:DI Z))
       C: (set (subreg:SI (reg:DI Z) 0) (... X ...))
       D: (set (subreg:SI (reg:DI Z) 4) (...))

  where B makes sure that Z is treated as dead before C.  Interblock
  motion causes B to be scheduled in an earlier block, but none of
  the other instructions can be.  This means that, when we schedule BB1,
  it still contains A, C and D, and Z now appears to be live on entry to
  the block.  C therefore appears to reduce register pressure, because
  it contains the last use of X, and appears to leave Z's liveness
  unaffected.  In reality it should be treated as increasing register
  pressure by 1 (-1 for the death of X, +2 for the birth of Z).

  I "fixed" this by moving C's dependencies to B, a bit like we do
  for scheduling groups (although none of the other handling of
  scheduling groups should apply).  This made a big difference,
  so that the new code is a win on RSA.

  There's still one SPEC2006 degradation on POWER7 that I want
  to look at.

* Caught up on a lot of mail.  gcc-patches backlog has gone down
  from ~4900 when I got back to ~500.

* Briefly looked at x86's drap support, to see what would be needed
  for ARM.  Didn't look for long though: the overhead seems excessive
  for optional alignment, and the agreement seemed to be that 128-bit
  alignment wouldn't really make much of a difference anyway.

Richard

_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Reply via email to