Re: simplify_subreg issues

[Mark Mitchell <mark at codesourcery dot com>]

>> 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 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
with a MEM in them until much later in the game.  (We're doing this
during the initial tree->rtl conversion.)  In fact, I wonder if
simplify_gen_subreg shouldn't abort in the case that it is given
a MEM that it cannot simplify away.  Oh, well.

What about just checking to see if the mode is one of the complex
modes, and ignoring MEM_VOLATILE_P in that case?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com