Re: [LTO] [PATCH] Avoid middle/back-end use of set_decl_assembler_name and tree_size lang hooks

[Mark Mitchell <mark at codesourcery dot com>]

Robert Kennedy wrote:

>> One of the open questions in the LTO design is to what extent (if at
>> all) RTL (as opposed to trees) should be saved/restored across
>> recompilation.
> 
> So my patch doesn't save RTL across recompilation.

Right, I understand.

>> I would have expected that the assembler-name hook for LTO would
>> abort if the assembler name was not already set, but otherwise be
>> tolerant.  If we adopt that approach, do we still need your change?
> 
> There are kind of two questions here, one about the longer term and
> one about the immediate short term.
> 
> Long term: I think ultimately LTO should not be treated as a language
> front end, and it should not have lang hooks at all.

I disagree -- slightly.  I think that thinking of LTO as a front end is
exactly the right model; it's input language happens to be object files
with magic sections, just as the GCJ input language is Java class files.
 But, in my mind, a front end is just something that takes some input
and generates GENERIC (or GIMPLE).

I think that lang hooks have gotten an overly bad name.  The key
principle is that lang hooks (or any other on-the-side data) should not
be required to interpret TREE; the meaning of TREE should be entirely
self-contained.  So, for example, it would be bad to have a lang hook
that says whether PLUS_EXPR is saturating; that should be encode as
SAT_PLUS_EXPR, or a IS_SATURATING bit on PLUS_EXPR, or an IS_SATURING
bit in the type, or something.  But, the mere existence of lang hooks
doesn't bother me at all.

In this case, for example, it might be that lazy loading is a win, and
that we would want to compute DECL_ASSEMBLER_NAME only when needed, by
going back to the DWARF and reading the data, for the (perhaps small)
minority of symbols for which we actually need this information.  Now, I
don't really expect that to be true; the file I/O required would be
prohibitive.  But, the point is that nothing about having a lang hook
for computing the assembler name is problematic with respect to
interpretation of TREE.

The other thing consideration here is pragmatic: the more we keep stuff
inside the LTO front end the better the chances we have at getting it
merged, and the less chance we have of breaking other front ends.

So, I think that the goal of having all the hooks removed from the
static call graph is overly strong.  Now, of course, we can't actually
do mangling, so having the hook assert that the value is already known,
and aborting if it isn't, is entirely reasonable.  Or, changing the
middle end not to call the hook if the name is already set (I thought it
already did that?) and then making the hook always abort is also fine
with me.

Thanks,

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