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

[Eric Botcazou]

> 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.

Thanks for the analysis.

> 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.

This comment, I presume:

      else if (GET_CODE (inner) == REG)
	{
	  /* We can't call gen_lowpart_for_combine here since we always want
	     a SUBREG and it would sometimes return a new hard register.  */

> 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.

Would it be sufficient anyway? Pseudo 33 would then be live on entry but not 
on exit, without being mentioned in-between.

> 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.

Clever. The attached patch indeed fixes the problem, by folding the former 
(sign_extend:DI (subreg:SI (reg:DI 32))).

Is it what you intended? If so, I'll test the patch on x86, SPARC32 and 
SPARC64 tomorrow.

-- 
Eric Botcazou
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr10983-2.diff
Type: text/x-diff
Size: 2437 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20030611/4bf61a70/attachment.bin>
-------------- next part --------------

;; Function static jint java::lang::Float::floatToRawIntBits(__java_float)

(note 1 0 31 ("<internal>") 5062)

;; Start of basic block 0, registers live: 14 [%sp] 23 [%l7] 31 [%i7] 33 [%f1] 101 [%sfp]
(note 31 1 3 0 [bb 0] NOTE_INSN_BASIC_BLOCK)

(note 3 31 4 0 NOTE_INSN_DELETED)

(note 4 3 10 0 NOTE_INSN_FUNCTION_BEG)

(note 10 4 11 0 ("<internal>") 5063)

(note 11 10 14 0 ("<internal>") 5064)

(note 14 11 15 0 NOTE_INSN_DELETED)

(note 15 14 18 0 ("<internal>") 5065)

(note 18 15 24 0 NOTE_INSN_DELETED)

(note 24 18 25 0 NOTE_INSN_FUNCTION_END)

(note 25 24 27 0 ("<internal>") 5066)

(insn 27 25 30 0 0x40731400 (set (reg/i:DI 24 %i0 [ <result> ])
        (sign_extend:DI (reg:SI 33 %f1 [ value+8 ]))) 148 {*sign_extendsidi2_insn} (nil)
    (expr_list:REG_DEAD (reg:SF 33 %f1 [ value ])
        (nil)))

(insn 30 27 0 0 0x40731400 (use (reg/i:DI 24 %i0 [ <result> ])) -1 (insn_list 27 (nil))
    (nil))
;; End of basic block 0, registers live:
 14 [%sp] 23 [%l7] 24 [%i0] 31 [%i7] 101 [%sfp]


;; Combiner totals: 4 attempts, 4 substitutions (1 requiring new space),
;; 3 successes.