Re: [lto]: PATCH: Add output of functions.

[Mark Mitchell <mark at codesourcery dot com>]

Steven Bosscher wrote:
> On Friday 08 September 2006 22:21, Steven Bosscher wrote:
> > On Friday 08 September 2006 17:33, Mark Mitchell wrote:
> > > As we've discussed, CONST_DECLs should be replaced with their
> > > DECL_INITIAL values.  That can happen in the gimplifier, or in your
> > > code, but there's no need to worry about how to write them out and
> > > there's no need to ever create a CONST_DECL in the reader.
> > I wasn't in that discussion so ignore me if the point is moot, but...
> >
> > How are you going to handle addressable CONST_DECLs?  The Fortran
> > front end (and probably other front ends) use such CONST_DECLs to
> > pass constants by reference.  Seems to me you can't replace those
> > with their DECL_INITIAL, and that you have to be able to write 'em
> > out and read 'em back in...?
>
> I hear this has already been discussed at length, so ignore me :-)

If gimplifying away CONST_DECL becomes hard, then we can always go 
another route.  However, it's not trivial to emit CONST_DECLs for LTO 
use either, since the DWARF generators currently ignore them.  So, we 
have to do work somewhere.  It some combination of teach DWARF about 
CONST_DECL, teach the gimplifier to eliminate CONST_DECL, teach Fortran 
not to use addressable CONST_DECLs, teach the LTO emission code to 
eliminate CONST_DECL, or something....

My preference remains to eliminate CONST_DECL in the gimplifier, and to 
make front ends that depend on addressable CONST_DECL use VAR_DECLs 
instead, perhaps with flags that allow multiple VAR_DECLs to be 
combined, as Joseph suggested.  That will eliminate some semantic 
confusion in GIMPLE, result in smaller on-disk images for LTO, and be 
simpler in the LTO front end.  However, if that plan proves 
substantially harder than inventing and implementing DWARF for them, 
then we can always reconsider.

--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713