Re: simplify_subreg issues

[Jan Hubicka <jh at suse dot cz>]

> 
> >> Are you saying that the use of `MEM_VOLATILE_P' is unncessary here,
> >> or that the MEM should nont be volatile, or that the MEM_VOLATILE_P
> >> test should be done only in conjuction with some additional check
> >> that says `and is not a complex type'?
> >
> > The last.  Something like HAVE_mov* where '*' is the mode, I think.
> 
> OK.  I assume that we can never get to this code with a user-defined
> type, even one like `struct S { float f; float g; };', followed by
> a structure copy of an instance of S?  If we can it seems like we should 
> handle that similarly, but I think we're not very clever, and just
> make S have BLKmode.
I believe we represent "short structures" as integer modes, so the
code will hit.
> 
> I guess this still feels a little fragile to me -- we're calling
> a function with simplify_gen_subreg in a situation where we definitely
> do not want `subreg' -- the manual says we should have no subregs
See code in simplify_gen_subreg:

rtx
simplify_gen_subreg (outermode, op, innermode, byte)
     rtx op;
     unsigned int byte;
     enum machine_mode outermode, innermode;
{
  rtx new;
  /* Little bit of sanity checking.  */
  if (innermode == VOIDmode || outermode == VOIDmode
      || innermode == BLKmode || outermode == BLKmode)
    abort ();

  if (GET_MODE (op) != innermode
      && GET_MODE (op) != VOIDmode)
    abort ();

  if (byte % GET_MODE_SIZE (outermode)
      || byte >= GET_MODE_SIZE (innermode))
    abort ();

  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 first part is catching obviously bogus calls and aborts.
The bottom part is catching bogus results - in case we are not able
to combine two SUBREGS or the operand is still VOIDmode.

Perhaps we can add the test for MEM as well and return 0.
Problem is that some callers (gen_lowpart mainly) require the
code to sucess. So operand_subword_force and friends will need to
be teached to load operand to register, that may cause infinite loops
in case MD file has expander that does move "by pieces".

About the MEMs on subregs.  I think we have two possibilities
1) allow them everywhere
2) avoid them everywhere

Maybe 2) makes sense.
Currently the do exist mostly in reload pass, but the reload
cleans them up, so it should not be too dificult to teach reload
to clean them up immediately and do not create them.

Similar is true about combine and cse, where we temporary
do create them, but never let them survive long.

But still there may be cases, where SUBREGs on mem make sense.
For instance on MEMs containing autoincrementing/decrementing
addresses, where it is not trivial to simplify the reference.

1) can be quite easy IMO, as what we currently do. All we need
is to update manual.

Honza