This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: TREE_READONLY in lookup_tmp_var
- From: Richard Henderson <rth at redhat dot com>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 20 Aug 2004 14:10:47 -0700
- Subject: Re: TREE_READONLY in lookup_tmp_var
- References: <10408202051.AA04794@vlsi1.ultra.nyu.edu>
On Fri, Aug 20, 2004 at 04:51:10PM -0400, Richard Kenner wrote:
> How? Those are the ones that are in the hash table. If they are overwritten
> then nobody else should be getting that same variable for the same value.
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.
> The most straightforward way of representing what this really looks like is:
>
> foo = { &{1, 3}, "abc"};
>
> Yes, a temporary could be made for the {1,3}, but the job of that part of the
> Ada front end is to make complex expression, letting the gimplifier
> put in any needed temporaries. That seems the right balance to me.
>
> The semantics of the above are fairly clear and it used to work.
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.
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?
r~