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

Robert Kennedy jimbob@google.com
Wed Mar 21 18:48:00 GMT 2007


> Very glad to see you working on this!

Thanks! It's short-lived for me, I'm afraid, but I'll be back to it in
six months or so. Others at Google are going to keep up the fight
while I do something else for a while.

> The lto/* changes are OK.  I didn't know about DW_AT_MIPS_LINKAGE_NAME;
> I was planning to invent an attribute for that.  I guess MIPS already
> did. :-)

Right. It would be nicer if the name were nicer. :-)

> However, I'm not really keen on the MBE_DECL_RTL idea.

Me either, but maybe our reasons are different.

> 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. It only saves the
assembler name, and rebuilds the RTL at LTO time. Whether the front
end should ever build RTL is a separate question (I feel that ideally
it shouldn't); that question is not (and should not be) addressed by
my patch.

Does the fact that we actually aren't saving RTL across the boundary
address your concern? My patch actually doesn't change anything about
what's saved across the boundary. All I did was add code to restore
something from the DWARF whose restoration had been overlooked (the
MIPS_linkage_name attribute), and then hacked around to make sure that
it would never get recomputed.

> 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. Obviously we
aren't there yet, but that's the future I am aiming toward with this
patch. That's why I want to replace as many of the LTO hooks as
possible with routines that simply assert. So we can ensure that we're
moving LTO toward never calling the hooks. The next step would be to
remove them statically from LTO, and MBE_DECL_RTL, ugly though it is
because it coexists with the old DECL_RTL, is meant to be a step
toward that. In my ideal vision of the future, DECL_RTL and
make_decl_rtl() go away because the front ends no longer build RTL at
all nor concern themselves with it in any way, and what I have called
MBE_DECL_RTL becomes the only such macro. Then we're back to non-ugly.

In the shorter term, your suggestion is a valid way to do it. But I
prefer getting the hooks out of LTO's call graph entirely where
possible, and that's why I chose as I did. If you insist, I could do
it your way and remove MBE_DECL_RTL, which I agree is ugly (but only
because it coexists with its front-endy friend, and I feel this is a
tolerable interim measure).

Thanks for your thoughts on this!

	-- Robert



More information about the Gcc-patches mailing list