Re: a strange infelicity of register allocation

[Jeffrey A Law <law at hurl dot cygnus dot com>]

  In message <199901252130.QAA07655@blastula.phys.columbia.edu>you write:
  > Current snapshot, -O2:
  > 
  > switch:
  > 	movb (%esi),%al
  > 	movb %al,-4125(%ebp)
  > 	incl %esi
  > 	xorl %eax,%eax
  > 	movb -4125(%ebp),%al
  > 	cmpl $10,%eax
  > 	je case_one
  > 	jg case_two_or_three
  > 	testl %eax,%eax
  > 	je case_four
  > 	jmp default
  > 	.p2align 4,,7
  > case_two_or_three:
  > 	cmpl $13,%eax
  > 	je case_two
  > 	cmpl $63,%eax
  > 	je case_three
  > default:
  > 	movb -4125(%ebp),%dl
  > 	movb %dl,(%ebx)
  > 	incl %ebx
  > 	jmp switch
  > 	.p2align 4,,7
  > ...
  > 
  > -4125(%ebp) will be in cache, of course, but this is still pretty
  > disgusting.
  > 
  > There is questionable code elsewhere, such as:
  > 
  > 	decl -4112(%ebp)
  > 	movl -4112(%ebp),%ecx
  > 
  > - if this were written the other way around, you'd avoid an address
  > generation, and a read-mod-write to memory; note that this particular
  > location is unlikely to be in L1.  Also the code would be smaller.
  > This looks like the problem Marc Espie keeps complaining about.
First, find out where and why we're getting this code.  Are we getting
reloads?  Look at the dump outputs, they're going to tell you more than
I ever could from looking at the assembly.

  > I think the key issue here is that it doesn't seem to know to preserve
  > values in call-saved registers over a function call.  It's somewhat
  > silly to be microoptimizing around a call to xrealloc, but this sort
  > of code is all over the place.
No, gcc knows how to do that just fine.  See caller-save.c.

It may be the case that it does not think it is profitable to do so.  If so,
you would need to find out why.

But the first and most important thing is to start looking at rtl, not
the assembly code and find out where things start to go wrong.  We can sit
here and speculate about caller-saves, regmove, register allocation, spills,
etc, but it does not do us any good.  You need to look at how we got to this
bad assembly code, step by step.  I recommend starting with either reload or
local allocation, then working either forward or backwards depending on what
you find.

jeff