Re: simplify_subreg issues

[Geoff Keating <geoffk at geoffk dot org>]

> Date: Tue, 12 Jun 2001 01:34:14 -0700
> From: Mark Mitchell <mark@codesourcery.com>
> cc: "kenner@vlsi1.ultra.nyu.edu" <kenner@vlsi1.ultra.nyu.edu>,
>         "jh@suse.cz" <jh@suse.cz>, "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
> Content-Disposition: inline
> 
> 
> >> 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?

I seem to remember some port that did actually have complex mode move
instructions.  In that case, you'd want to do

(set (reg:SC foo) (mem:SC ...))
(set (subreg:SF (reg:SC foo) 0)  whatever)
(set (mem:SC ...) (reg:SC foo))

Think here of a hardware register, which is sensitive to 8-byte or
4-byte accesses.

-- 
- Geoffrey Keating <geoffk@geoffk.org>