Re: a strange infelicity of register allocation

[Jeffrey A Law <law@hurl.cygnus.com>]

  In message < 199901290227.VAA29500@blastula.phys.columbia.edu >you write:
  > ;; Register dispositions:
  > 27 in 5  28 in 3  33 in 0  36 in 3  37 in 4  38 in 0  
  > 40 in 0  43 in 0  50 in 4  57 in 0  69 in 0  73 in 0  
  > 79 in 0  80 in 0  85 in 0  90 in 0  92 in 3  94 in 0  
  > 
  > ;; Hard regs used:  0 1 3 4 5 6 7 16
  > 
  > The source that got this dump is rather different from the source I sent
  > this morning, in particular register numbering is totally shuffled.  I
  > don't know why it wants to use hard reg 0 for so much stuff.  The
  > final assembly is decent, but it doesn't use register C (==2) at all.
Well, %eax is used most often because it's the first one listed in
REG_ALLOC_ORDER.  It's also automatically preferred for anything that is a
return value, or copied from a return value.

  > Where do I start diving?
Much like we did last time.

Find the first reg in the list of regs that are candidates for global
allocation.  Verify that #uses > 4 * # calls crossed.  Then put a breaking
in global.c:find_reg and step through it to find out why it's not getting
a hard reg.

  > It was a lose here because it caused a register spill in the common
  > case - but I don't know if gcc could've known it was the common case.
  > Profile-directed feedback anyone?
Well, we've got a few things that can be examined to build some heuristics
around.

We've got conflict lists.  If tying expands the conflict list, then that's
not good.  The question is how much expansion is too much expansion.

We've got lots of counters.

One could envision a heuristic like "the allocation priority of the tied
regs must be within some delta of the maximum of the alloation priorities of
the individual regs".  And the delta would inversely related to the expansion
of the conflict list.

Just a thought.  I've never tried anything like it.


  > The dump is from initial rtl generation, but reg 44 isn't dead at this
  > point in the code.  However, on x86, it's dirt cheap to rewrite the
  > above to (set (reg:SI 76) (zero_extend:SI (mem:QI (reg:SI 27))) and
  > then replace (reg:QI 44) with (subreg:QI (reg:SI 76)) wherever it
  > appears.  We don't do that.  It would be a big win: it reduces
  > register pressure (always good on x86) and it would enable
  > optimizations based on known contents of reg 76.  This particular
  > function benefits from both.
There's definite inconsistencies in our usage of zero-extend vs subregs on the
x86.  We were never able to reach any kind of conclusion about which one was
better to bias towards.

  > For starters, we seem to leave space for stack slots that are never
  > used; that should be easy to fix, no?
Depends on why they're unused.  Never assume anything is easy until you find
out why it's happening.

For example, maybe they're unused because reload inheritance eliminated the
need to ever store a value into those slots.  By the time we make that kind of
determination it's too late to eliminate the slot.  Similarly for reload_cse
eliminating the need for some slots.

Jeff