This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: simplify_subreg issues
- To: mark at codesourcery dot com
- Subject: Re: simplify_subreg issues
- From: Geoff Keating <geoffk at geoffk dot org>
- Date: Tue, 12 Jun 2001 01:31:04 -0700
- CC: kenner at vlsi1 dot ultra dot nyu dot edu, jh at suse dot cz, gcc at gcc dot gnu dot org
- References: <212030000.992320776@gandalf.codesourcery.com>
- Reply-to: Geoff Keating <geoffk at redhat dot com>
> Date: Mon, 11 Jun 2001 21:39:36 -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
>
>
> > The underlying problem is that 'volatile' doesn't make sense in
> > conjunction with 'complex'. We can't do complex loads or stores. So,
> > actually in this case the optimisation would be correct, because what
> > we want to have is
> >
> > (set (mem/v:SF ...) ...)
> >
>
> I don't really understand what we do with `volatile' on a structure
> type, in general, or what the standard says we have to do.
The standard says nothing meaningful about 'volatile'. We can do
whatever we think would be useful or convenient.
> I guess one would like to avoid `f(y)' -- where `y' is some
> volatile complex type -- generating more than one reference to any
> word in `y'.
That sounds reasonable.
> 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.
--
- Geoffrey Keating <geoffk@geoffk.org>