This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Mark Mitchell wrote:
> Andrew Pinski wrote:
>> On Mon, 2006-09-04 at 18:55 +0000, Joseph S. Myers wrote:
>>> You could add a bit on VAR_DECLs which says to apply
>>> -fmerge-all-constants semantics to that VAR_DECL.  (And then
>>> -fmerge-all-constants might apply that bit to all constant variables.)
>>
>> Then why have CONST_DECLs in the first place?  I don't see why the
>> front-ends would need a CONST_DECL either.  Yes for enums you cannot
>> take the address of their name, then why not make CONST_DECLs local to
>> the C/C++ front-ends instead?
>
> From a code-generation point of view, it would be fine for CONST_DECLs
> to be local to front ends.  It's also fine for them to be in the
> middle end, if they're useful in the same way to several front ends,
> just as we provide other utility routines in the middle end,
>
> Front ends do need CONST_DECLs, or something like them, because they
> have to map the names the user types to something.  CONST_DECLs are
> what you put in the symbol table to associate a name with a value.  At
> present, they are also used for generating debugging information --
> which is essentially a mechanism for passing the symbol table to the
> debugger.
>
As people from the southern part of the US are fond of saying (and I am
originally from Louisiana): I do not have a dog in this fight. 

Dealing with const_decls is, in many ways similar to the issue having to
attach a type to every tree node.  A design flaw that people are
passionate about talking about fixing but we have never gotten it fixed
yet.

I can just skip these, or abort, which will be fine for the next week or
so while I get the bugs out of the reader.  But Mark, I believe you have
to make the decision since you know more of the relevant code, if it
will be faster to get rid of CONST_DECL or add the Dwarf support code
for it.  This is the same kind of call you made on the types and you
need to make a decision so we can just move on.   

I did not mean to open up an open discussion.  However the way that I
develop code is to write something and run it through everything (or at
least all of gcc), and so const decls happen.

Depending on what you decide, I think that I also will have to deal with
const_decls, as well as the full complement of types.  I really do not
think that it is my place to have the lto output and input be the
transformer here, because it guarantees that we will not be able to
verify that we are getting out what we are putting in.  And doing that
is an integral part of my design. 

Kenny


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]