Re: Why does sparc build for you? or,why are make check results reported when it hasn't bootstrapped since May 5?

[Jim Wilson <wilson at tuliptree dot org>]

The combine input uses (reg:SF 33) and has a REG_DEAD note for it.  The 
combine output uses (reg:DI 32) but still has the (reg:SF 33) REG_DEAD 
note.  Thus combine made r32 live in the function, and the consistency 
checking code validly complains about this.

The problem seems to arise in make_compound_operation/make_extraction. 
We start with (sign_extend:DI (reg:SI 32)).  make_compound_operation 
converts this to (ashiftrt:DI (ashift:DI (reg:DI 32) 32) 32).  Then 
make_extraction converts this to (sign_extend:DI (subreg:SI (reg:DI 
32))).   We should have gotten back the same register RTL at the end 
that we had at the beginning.  Thus assuming that combine is supposed to 
work for hard registers, one of these two routines is broken.  I am 
wondering if perhaps make_compound_operation broke as a side-effect of 
simplify_gen_subreg related changes.  Or it may be that this has been 
broken for a long time.

There is curious code in make_extraction which deliberately avoids 
calling gen_lowpart, and instead explicitly makes a SUBREG.  There is a 
comment that claims we must have a SUBREG here.  Perhaps this is out 
dated.  We could try using gen_lowpart here to see if it works.  This 
will have unpredicable effect though, so it isn't clear if it is safe. 
This needs to be investigated.

An alternative solution would be for combine to try to notice when it it 
has changed the size of a register, and adjust the REG_DEAD note, but I 
suspect this will be hard because we don't have easy access to the info 
we need.

I looked at make_extraction more closely.  The call to 
gen_lowpart_for_combine was removed here:

Sat Jun 20 06:32:11 1992  Richard Kenner  (kenner at vlsi1.ultra.nyu.edu)


        * combine.c (make_extraction): Always ensure we have a SUBREG when
        we make a STRICT_LOW_PART.

However, this code is used for both when the operand is !in_dest, and 
for the case when STRICT_LOW_PART is available.  So it looks like this 
might have been broken since the beginning.  If !in_dest is true, we 
should be able to use gen_lowpart_for_combine here, and that will fix 
the sparc build problem.  Hopefully without causing other build problems.

Jim