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]
Other format: [Raw text]

Re: TREE_READONLY in lookup_tmp_var


    They'll get the same variable when the expression is used with the
    same inputs.  The inputs are not constrained such that they must
    have the same values.  You'll notice that there is absolutely no
    invalidation out of that hash table.

    It is a misunderstanding on your part what this is for -- the sole
    purpose of this hash table is reducing the number of temporary
    variables, not doing SSA or CSE.

No, you misunderstood me.

If the hash table is giving, say, T.78 as the value of "X + Y" and T.78
isn't really readonly (meaning it's modified), then another request
for "X + Y" shouldn't give T.78 as that's no longer it's value.

(And I must admit that I never thought of the issue of invalidation.  So how
*does* it work if X, in the example above, were changed: T.78 wouldn't
have changed.)

    It still does.  The gimplifier followed all of rules that you gave it.
    It put { 1, 3 } into a memory location and gave you the address.  It's
    your fault for wanting something more specific than that.

As I said, I think the usage is somewhat bogus, but the point is that
it's more efficient code anyway to do that: if you end up taking the
address of a constant CONSTRUCTOR it's never more efficient to generate
inline code for it.

    I think it should be up to you to put this in static memory if that's
    what you need.  Which is only to wrap the CONSTRUCTOR in a CONST_DECL
    or VAR_DECL with TREE_STATIC+TREE_READONLY set.  Why is that so hard?

It's not "hard", it's just that it's not consistent with the way the rest of
the expressions are handled and I'm also not sure that the knowlege that a
global is involved is known at the right level.

The issue is that we want to have a pretty clear 1-1 correspondance between
Ada and GCC tree nodes for expressions.  Right now, we don't store that data,
but there have been proposals to move the generation of GCC trees earlier
into the front end processing in the hope of having the high-level code know
more about lower-level issues (such as layout) than it does now.

If we "throw off" some statement (such as a DECL_EXPR for the variable)
within the processing of an expression, it makes it harder for the
expression to stand alone.

So if this is viewed as the best route, I think the appropriate level for
it would be in the Ada gimplification routine.  But I still think that
it's a efficiency bug that we don't put such a CONSTRUCTOR into static
memory anyway.


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