This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: TREE_READONLY vs TREE_CONSTANT
- From: Richard Henderson <rth at redhat dot com>
- To: Josh Conner <jconner at apple dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 24 Aug 2005 12:33:54 -0700
- Subject: Re: TREE_READONLY vs TREE_CONSTANT
- References: <72C9070D-E64F-4B3D-942C-B62217C53AEC@apple.com>
On Wed, Aug 24, 2005 at 11:10:38AM -0700, Josh Conner wrote:
> Can someone provide a bit of insight here - what is the difference
> between TREE_READONLY and TREE_CONSTANT (and why is TREE_READONLY the
> one that ipa-reference should be setting)?
It depends on what property IPA is computing. And they aren't
terribly differentiated.
TREE_CONSTANT corresponds to the C++ "const int i = 1". That is,
the variable may be immediately replaced in context with the
immediate value, and unless the address of I is taken, its symbol
will not appear in the assembly file.
We probably could set TREE_CONSTANT for C "static const int i = 1",
but to-date the optimizations that would enable are already taken
care of by other means.
TREE_READONLY means that the decl is not modifyable. It is
interpreted, then, that the variable ought to go into read-only
storage.
The problem demonstrated in this PR comes when we combine this
with variables in user defined sections. We take TREE_READONLY to
infer the flags that should be applied to the section. Since a
section can only have one set of flags, we define that the user
must use the same set of flags for all variables in the section.
The IPA pass indiscriminately setting TREE_READONLY breaks this.
It's clear that we want IPA to set TREE_READONLY when the
variable isn't in a user-defined section, so that if there is
something that truely forces the variable into memory, that we
put it in read-only storage.
Which leaves the question of what IPA should do with variables
that are in user-defined sections, and still gain the benefit
of the IPA analysis?
My suggestion is that IPA sets TREE_CONSTANT for all variables
that it determines are unchanged, and TREE_READONLY as
constrained by DECL_SECTION_NAME. We'll then have to modify a
couple of places in the optimizers to check TREE_CONSTANT or
TREE_READONLY. Finally, modify the front ends to set
TREE_CONSTANT right away when it makes sense, and then we can
remove the duplicated check in the optimizers.
I'm not sure how much of this will be possible before 4.1 is
released. At minimum we have to change IPA to stop setting
TREE_READONLY when DECL_SECTION_NAME is set; if we have to
live with reduced optimization so be it.
r~