This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: simplify_subreg issues


> 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>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]