> On Mon, Mar 04, 2013 at 01:42:51PM +0100, Richard Biener wrote: > > When inlining call stmts with a NULL gimple_block we still remap > > all the callee blocks into a block tree copy but we'll end up > > not referencing it from anywhere. This causes verification failures > > because then we have nothing refering to the inline stmt blocks. > > Ugh, best would be to set proper block even for the artificially added calls > (whether to look around for surrounding statement blocks or similar).
As I added to the PR log, I do not really think we can LTO reliably libraries, like libgcov, where backend invents its own calls. For safe LTO of runtime bits (libgcc/libgcov/libc) we will need a mechanizm to explicitly mark implementations of runtime calls and do not remove them from callgraph until it is clear that no new calls are invented. > > Because clearing the block tree will have the nasty effect that nothing > in the inlined routine will be debuggable. Attaching the block tree to > DECL_INITIAL isn't very good either, because while the inline fn itself > will be debuggable, the parent function's variables won't be accessible. > > But I guess your patch is fine as a hack to avoid ICEs, and we just should > try harder and harder to avoid ever hitting that situation. Well, what would you recommend to do when adding an instrumentation calls on random places of the callgraph? We do 1) adding the counter increments that are associated with edges in callgraph. 2) adding VPT calls that are associated with an instruction (like divide) 3) adding calls to prologue handling indirect call. I suppose 3) can be handled same way as prologue code and 2) can copy block from the associated instruction. But what should we do for 1? Honza > > Jakub