This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: MEM_COPY_ATTRIBUTES
- To: mark at codesourcery dot com
- Subject: Re: MEM_COPY_ATTRIBUTES
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Date: Wed, 3 May 00 14:59:44 EDT
- Cc: gcc at gcc dot gnu dot org
That's not necessarily so -- even if it happens in most of the places
you looked.
Actually, it's in all except for one or two and I think those should
have it too (I *know* that one not having it is a bug).
There are two different concepts here: making a related version (i.e.,
smaller or larger view) of an existing MEM, and making a new MEM that
happens to share some properties of an existing MEM (i.e., say,
allocating stack space to store a temporary version of a global
variable, or duplicating a local variable during loop-unrolling.)
What does "some" mean? That's the key point as I see it. Right now,
we've picked a peculiar subset of the properties. I can't see why
volatility is a property that would be useful to copy in cases when
readonly isn't. Why make that distinction?
Note also that I think it is safe to always copy MEM_ALIAS_SET because
that alis can always safely be used to reference a component: it's just
that in some cases you might be able to find a *better* alias set for
that component.