Re: [lto] PATCH: Add support for referencing types from function bodies

[Paul Schlie <schlie at comcast dot net>]

> Andrew Pinski wrote:
>> On Mon, 2006-09-04 at 10:51 -0700, Mark Mitchell wrote:
>> I think Fortran and Objective-C should change, and that they may need to
>> change in order to work with LTO. I think that, as in C/C++, a VAR_DECL
>> with TREE_READONLY should be used instead, and that CONST_DECLs should
>> never be addressable.
> 
> Why? The reason why it was done was to save space and make sure they
> are really put in the constant section. I don't see a reason why they
> should be using VAR_DECLs.
>
> VAR_DECLs should be used for data objects that potentially take up space
> in the object file. Whatever you might hope to accomplish with a CONST_DECL
> can equally well be accomplished with a VAR_DECL with a bit that says it is
> a constant.

- Yes, and as a true constant is never modified or assigned, no "RAM"
  storage need be allocated, as it's value does not need to be copied from
  it's constant storage area typically in "ROM" to be referenced; as ideally
  typical of embedded systems where "RAM" may be precious.

> All of the issues you raise point to failures to optimize appropriately,
> not to something about the choice of representation. In other words, if the
> optimizers figure out that, given, "const int i = f();" the value of "f" is
> always "3", then "i" ought to be treated just like a CONST_DECL for 3.

- Yes, thereby likely best to declare "i" initially as a read/init variable
  being assigned the value resulting from the function call at runtime, but
  not a read-only constant until it's value may be definitively determined
  during compilation.

> Fundamentally, all a CONST_DECL gives you is a name for a constant. But,
> there's no advantage to having names when optimizing; you might as well
> just use the constant. If there's really a need for ADDR_EXPR (CONST_DECL),
> it would be simpler just to allow ADDR_EXPR (INTEGER_CST).

- Thereby there's truly 3 fundamental types of declarations, where the first
  2 below in effect represent VAR_DECL's being initialized with a constant
  read-only value, and the 3rd representing a true read-only value which
  may either be in-lined as an immediate value in the code or referenced by
  it's address directly from within a constant section as may be allocated
  in ROM) as best determined by the back-end code generator if not already
  eliminated through constant-folding or dead-code elimination by the
  middle-end. The three being:

      int x = 3   :: (DECL "x" <read/write> <int> 3) :: VAR_DECL read/write

const int x = f() :: (DECL "x" <read/init> <int> 3)  :: VAR_DECL read/init

const int x = 3   :: (DECL "x" <read-only> <int> 3)  :: CONST_DECL read-only

Thereby seemingly CONST_DECL may be eliminated if VAR_DECL could be
extended to enable the differentiations between read/init and read-only
access/allocation constraints?