Re: MEM_COPY_ATTRIBUTES

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Richard" == Richard Kenner <kenner@vlsi1.ultra.nyu.edu> writes:

    Richard>     I don't know.  I don't see why if one MEM is
    Richard> unchanging another one should be, just because it happens
    Richard> to have the same volatility, and scalarness, say.

    Richard> The idea is that it's referencing the same thing, or a
    Richard> part of the same thing.

That's not necessarily so -- even if it happens in most of the places
you looked.

    Richard>     It might again be reasonable for MEM_COPY_ATTRIBUTES
    Richard> to take an UNCHANGING_P parameter so that users were
    Richard> forced to decide this issue -- but I don't think just
    Richard> copying is right.

    Richard> So far the first few cases I saw are copying it too.
    Richard> I'll take a look at each usage and see what's right.  My
    Richard> best guess is that it's unlikely that not copying it is
    Richard> ever right.

I disagree.

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

In the first case, your argument makes sense.  In the second, it
doesn't.

MEM_COPY_ATTRIBUTES is supposed to work in both cases.

A new macro, MEM_MAKE_VARIANT (horrible name, I know -- we need a
better one) could be used to say `This MEM is a piece of that MEM, or
a wider version of it, or something like that.'  This new macro could
be implemented by using MEM_COPY_ATTRIBUTES, plus some stuff that
would copy UNCHANGING_P.

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