This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Question regarding ICE in instantiate_virtual_regs_1, at function.c:3880
> > > I have come to the conclusion that there is a problem with
> > > GO_IF_LEGITIMATE_ADDRESS on the vax (ie, it shouldn't accept a
> > > DCmode MEM with the above indexing) since the maximum number
> > > of bytes that can be moved in a single insn is 8.
> > Yes, this is the complex type hackery - basically it does the DC modes behind
> > scene w/o validation from backend splitting it later.
> > What you need is to figure out from where the subreg is comming and replace
> > gen_SUBREG by simplify_gen_subreg. That should be enought I guess.
> >
> > In case simplify_gen_subreg for some purpose refuse to simplify memory in question,
> > let me know.
>
> The subreg is coming from simplify_gen_subreg:
>
> new = simplify_subreg (outermode, op, innermode, byte);
> if (new)
> return new;
>
> if (GET_CODE (op) == SUBREG || GET_MODE (op) == VOIDmode)
> return NULL_RTX;
>
> return gen_rtx_SUBREG (outermode, op, byte);
> }
>
> The call to simplify_subreg us not successful because mode_dependent_address_p
>
> returns true for:
>
> (plus:SI (mult:SI (reg:SI 21)
> (const_int 16 [0x10]))
> (mem/f:SI (reg/f:SI 16 virtual-incoming-args) [0 t+0 S4 A32]))
>
> At the moment, GO_IF_MODE_DEPENDENT_ADDRESS only accepts a plus with
> a register and a constant address.
I see. This is somewhat unfortunate.
What I was thinking about is to add simplify_subreg_force wrapper that will
do converison even if it looks wrong (resulting address is invalid or resulting
register having not valid mode).
This is usefull for few other places too (alter_subreg, split_di), perhaps it
can be used here too. Sound sane?
Honza
>
> Dave
> --
> J. David Anglin dave.anglin@nrc.ca
> National Research Council of Canada (613) 990-0752 (FAX: 952-6605)