[PATCH] Introduce instance discriminators

Alexandre Oliva oliva@gnu.org
Thu Jul 19 07:21:00 GMT 2018


On Jul 18, 2018, Richard Biener <richard.guenther@gmail.com> wrote:

> On Wed, Jul 18, 2018 at 8:53 AM Alexandre Oliva <oliva@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.  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



More information about the Gcc-patches mailing list