On Thu, Jul 19, 2018 at 9:21 AM Alexandre Oliva <ol...@gnu.org> wrote: > > On Jul 18, 2018, Richard Biener <richard.guent...@gmail.com> wrote: > > > On Wed, Jul 18, 2018 at 8:53 AM Alexandre Oliva <ol...@gnu.org> wrote: > >> Instance discriminators are not compatible with LTO, in that the > >> instance mapping is not preserved in LTO dumps. There are no plans to > >> preserve discriminators in them. > > > Because... > > ... it follows existing practice. BB discriminators are not saved for > LTO either.
Oh, that probably wasn't omitted on purpose. Cary said it was used for profiling but I can't see any such use. Is the instance discriminator stuff also used for profiling? I agree that coverage probably isn't depending on LTO. > They could be saved along with the CFG, but AFAICT they > aren't. As for instance discriminators, we might be able to save them > along with LOC information, but that would be quite wasteful, and > because of the way ordinary maps are reconstructed when reading in the > LTO data, we'd end up with yet another internal representation for > line_maps. I was told there was no interest from our customers in using > the converage and monitoring aspects of instance discriminators when > performing link-time optimizations, and thus that it made sense to > follow existing practice. > > > I suspect there might be a way to assign instance discriminator numbers > to individual function DECLs, and then walk up the lexical block tree to > identify the DECL containing the block so as to obtain the discriminator > number. This would be a lot less efficient, algorithmically speaking, > but, provided that LTO dumps discriminator numbers as part of the decls, > and enough info to reconstruct the lexical block trees, including the > inlined-function enclosing blocks, that should work even for LTO, at > least as long as different decls are maintained for each instance. > > Indeed, if this is the case, code ranges of lexical blocks in inlined > subroutines would suffice to identify each instantiation, without the > need for discriminators. It would be a lot more expensive to gather the > information from that debug info than from discriminators, though. > > All this said, there doesn't seem to be much interest in that from Ada > users to justify by itself the pursuit of yet another internal > representation. I wonder if this sort of discriminator might be of > interest for users of C++ templates as well. > > -- > Alexandre Oliva, freedom fighter https://FSFLA.org/blogs/lxo > Be the change, be Free! FSF Latin America board member > GNU Toolchain Engineer Free Software Evangelist
