public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* TREE_READONLY vs TREE_CONSTANT
@ 2005-08-24 18:57 Josh Conner
  2005-08-24 22:20 ` Richard Henderson
  0 siblings, 1 reply; 3+ messages in thread
From: Josh Conner @ 2005-08-24 18:57 UTC (permalink / raw)
  To: gcc

In looking at PR23237, I ran into a bit of confusion over the  
difference between TREE_READONLY and TREE_CONSTANT.  Andrew Pinski  
indicated in PR logs that I am misunderstanding their uses, so rather  
than bogging down the PR logs trying to clear up my confusion (which  
isn't really fair to Andrew), I thought I would bring up the question  
in a more general forum to see if there is someone willing to offer  
some insight.

In the example from this PR, the TREE_READONLY attribute of a static  
variable declaration is being set in the ipa-reference pass if is  
determined that the variable is never modified.  The problem is that  
when the assembly code is generated for this variable, the section  
flags are also set based on TREE_READONLY, so it ends up in a section  
inconsistent with its declaration.

When I started digging into the tree flags, the descriptions in  
tree.h seemed to imply that TREE_CONSTANT is the appropriate  
attribute for a variable whose value doesn't change:

     /* Value of expression is constant.  Always on in all ..._CST  
nodes.  May
        also appear in an expression or decl where the value is  
constant.  */
     #define TREE_CONSTANT(NODE) (NON_TYPE_CHECK (NODE)- 
 >common.constant_flag)

And, based on other bits of source, TREE_READONLY seems to represent  
whether the variable was actually declared constant.

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

Thanks for any help you can offer.

- Josh

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: TREE_READONLY vs TREE_CONSTANT
  2005-08-24 18:57 TREE_READONLY vs TREE_CONSTANT Josh Conner
@ 2005-08-24 22:20 ` Richard Henderson
  2005-08-24 22:55   ` Josh Conner
  0 siblings, 1 reply; 3+ messages in thread
From: Richard Henderson @ 2005-08-24 22:20 UTC (permalink / raw)
  To: Josh Conner; +Cc: gcc

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~

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: TREE_READONLY vs TREE_CONSTANT
  2005-08-24 22:20 ` Richard Henderson
@ 2005-08-24 22:55   ` Josh Conner
  0 siblings, 0 replies; 3+ messages in thread
From: Josh Conner @ 2005-08-24 22:55 UTC (permalink / raw)
  To: gcc; +Cc: Richard Henderson


On Aug 24, 2005, at 12:33 PM, Richard Henderson wrote:

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

Thanks very much for the thorough description.  I think I understand  
the distinction now.

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

I'd be glad to create and test a patch for this, if it would be  
welcomed.

- Josh

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2005-08-24 21:40 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-08-24 18:57 TREE_READONLY vs TREE_CONSTANT Josh Conner
2005-08-24 22:20 ` Richard Henderson
2005-08-24 22:55   ` Josh Conner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).