Re: [PATCH] Optimize subregs of zero and sign extensions (take 2)

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

Hi Roger,

On Wed, Jan 21, 2004 at 07:10:11PM -0700, Roger Sayle wrote:
>       * rtlanal.c (subreg_lsb_1): New function split out from subreg_lsb.
>       (subreg_lsb): Change to call new subreg_lsb_1 helper function.
>       * rtl.h (subreg_lsb_1): Prototype here.
>       * simplify-rtx.c (simplify_subreg): Optimize subregs of zero and
>       sign extensions.

I haven't checked for sure but I think this patch is likely the cause
of the following ICE on hppa64-hp-hpux11.11:

./xgcc -B./ -B/opt/gnu64/hppa64-hp-hpux11.11/bin/ -isystem /opt/gnu64/hppa64-hp-hpux11.11/include -isystem /opt/gnu64/hppa64-hp-hpux11.11/sys-include -L/xxx/gnu/gcc-3.3/objdir/gcc/../ld -O2  -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fPIC -Dpa64=1 -DELF=1 -mlong-calls -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I -I../../gcc/gcc -I../../gcc/gcc/ -I../../gcc/gcc/../include   -DL_divdi3 -c ../../gcc/gcc/libgcc2.c -fexceptions -fnon-call-exceptions -o libgcc/./_divdi3.o
../../gcc/gcc/libgcc2.c: In function `__divdi3':
../../gcc/gcc/libgcc2.c:1019: internal compiler error: in simplify_gen_subreg, at simplify-rtx.c:3442

We have in frame 1:

#1  0x400000000056630c in simplify_gen_subreg (outermode=HImode, 
    op=0x800003fffeb22240, innermode=SImode, byte=6)
    at ../../gcc/gcc/simplify-rtx.c:3442
3442        abort ();
(gdb) p debug_rtx (op)
(reg:SI 373)

While we are on the subject of SUBREGs, I started looking at the
failure of funcorder.c on this port.  After CSE, we have:

(insn 11 10 12 0 (set (reg:SI 71 [ mem ])
        (mem/f:SI (reg/f:DI 69) [2 mem+0 S4 A32])) 70 {*pa.md:2265} (nil)
    (nil))

(insn 12 11 15 0 (set (reg/v:DI 68 [ t ])
	(sign_extend:DI (reg:SI 71 [ mem ]))) 137 {extendsidi2} (nil)
    (nil))

[... including const call]

(jump_insn 25 17 45 0 (set (pc)
        (if_then_else (eq (reg:SI 71 [ mem ])
		(subreg/s:SI (reg/v:DI 68 [ t ]) 4))
	    (label_ref 29)
	    (pc))) 46 {*pa.md:1674} (nil)
    (nil))

We eventually end up with the following code:

        ldw 0(%r19),%r5			; zero extended value is load into r5
	extrd,s %r5,63,32,%r19		; sign extend least significant 32 bits
					; of r5 and put into r19
	cmpb,= %r19,%r5,L$0003		; so we end up comparing zero extended
					; value of mem with sign extended
					; (promoted) value

I'm still not sure why the test fails as the sign extension and zero
extension of 0 are the same.  However, I don't think we should be
comparing sign and zero extended values.  Thoughts?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)