This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Question about SUBREG handling in get_last_value
- From: Jan Hubicka <jh at suse dot cz>
- To: John David Anglin <dave at hiauly1 dot hia dot nrc dot ca>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 28 Nov 2001 10:12:48 +0100
- Subject: Re: Question about SUBREG handling in get_last_value
- References: <200111271832.fARIWc0F019599@hiauly1.hia.nrc.ca>
> In looking at the testresults for hppa64-hp-hpux11.00, there are a few
> FAILs due to aborts in simplify_gen_subreg when it is called with
> innermode==VOIDmode. This happens for example in compile/20000420-2.c
> at -O1.
>
> The problem arises with this situation in get_last_value:
>
> (gdb) p debug_rtx (x)
>
> (subreg:SI (reg:DI 28 %r28) 4)
>
> (gdb) p debug_rtx (reg_last_set_value[28])
>
> (call (clobber:SI (const_int 0 [0x0]))
> (const_int 64 [0x40]))
>
> As can be seen, the last value is VOIDmode and the attempt to
> simplify it in gen_lowpart_for_combine leads to the abort. It
> looks like `clobber:SI (const_int 0 [0x0])' might have been
> substituted before the call to last value where the abort
> occurs.
>
> Should get_last_value not call gen_lowpart_for_combine when the
> last value is VOIDmode or does gen_lowpart_for_combine need fixing
> so it doesn't call simplify_gen_subreg with innermode=VOIDmode?
I guess the proper fix is to simplify the subreg while doing the
replacement and thats what should happen in the subst function.
Do you know where exactly the value is replaced and why the mode
is lost? See how combine_simplify_rtx keep the original mode
before substitution so the simplify_subreg is happy.
Honza
>
> Dave
> --
> J. David Anglin dave.anglin@nrc.ca
> National Research Council of Canada (613) 990-0752 (FAX: 952-6605)