llvm dev - Nov 2018 - DebugInfo proposal: Emit an explicit empty address range on CUs with no code addresses

So I've been looking at a particular performance problem with LLVM's
symbolizer due to the use of ThinLTO, split DWARF, and split DWARF inlining
info.

This combination has a couple of problems:

1) it means multiple CUs in a single DWO, which isn't well
defined/specified, and best avoided - so I'm working on fixing that here
(won't fix split DWARF+Full LTO) because we already don't use cross-CU
references in the split units (because there's no supported way to express
that in DWARF), so we clone/move any DIEs (like subprograms) referenced
cross-CU into the CU that references them (eg: cross-CU inlining places the
abstract subprogram definition for the inlined subroutine into the CU that
has the inlining - rather than cross-CU referencing into the other CU)) -
and in ThinLTO the only reason other units exist is to cross-CU
optimize/inline, no code for imported CUs is ever emitted (except where
it's been inlined) - so a ThinLTO compile has one primary unit, and some
other units it inlines from - so those other units never emit anything in
the split unit, just a few DIEs in the skeleton unit if you're using split
DWARF inlining (or no unit at all if you aren't using that feature) - so
I'm working on making it so those units are non-split (rather than having a
degenerate/empty split unit)

2) symbolizer performance is hurt because whenever it sees a unit without
ranges at the unit DIE, it assumes the producer just skipped those - and
goes searching through the implementation DIEs (which may mean going over
to the .dwo, or loading a whole .dwp) to see where their addresses are.

It's this second step that's a bit painfully unnecessary, especially for
a
large DWP on a remote filesystem, etc.

So, anyone have opinions on whether we should

a) decide that a unit without ranges covers no ranges - and don't do the
search

b) emit zero-length ranges on any unit that has no code ranges (low/high pc
zero? Could pick anything, but that seems the most obvious)

Thanks,
- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181128/ef4fe67c/attachment.html>

> On Nov 28, 2018, at 9:40 AM, David Blaikie <dblaikie at gmail.com>
wrote:
> 
> So I've been looking at a particular performance problem with
LLVM's symbolizer due to the use of ThinLTO, split DWARF, and split DWARF
inlining info.
> 
> This combination has a couple of problems:
> 
> 1) it means multiple CUs in a single DWO, which isn't well
defined/specified, and best avoided - so I'm working on fixing that here
(won't fix split DWARF+Full LTO) because we already don't use cross-CU
references in the split units (because there's no supported way to express
that in DWARF), so we clone/move any DIEs (like subprograms) referenced cross-CU
into the CU that references them (eg: cross-CU inlining places the abstract
subprogram definition for the inlined subroutine into the CU that has the
inlining - rather than cross-CU referencing into the other CU)) - and in ThinLTO
the only reason other units exist is to cross-CU optimize/inline, no code for
imported CUs is ever emitted (except where it's been inlined) - so a ThinLTO
compile has one primary unit, and some other units it inlines from - so those
other units never emit anything in the split unit, just a few DIEs in the
skeleton unit if you're using split DWARF inlining (or no unit at all if you
aren't using that feature) - so I'm working on making it so those units
are non-split (rather than having a degenerate/empty split unit)
> 
> 2) symbolizer performance is hurt because whenever it sees a unit without
ranges at the unit DIE, it assumes the producer just skipped those - and goes
searching through the implementation DIEs (which may mean going over to the
.dwo, or loading a whole .dwp) to see where their addresses are.
> 
> It's this second step that's a bit painfully unnecessary,
especially for a large DWP on a remote filesystem, etc.
> 
> So, anyone have opinions on whether we should
> 
> a) decide that a unit without ranges covers no ranges - and don't do
the search
Are there compilers that do this ("forget" to emit ranges) that we
care to support with llvm-symbolizer?

-- adrian
> 
> b) emit zero-length ranges on any unit that has no code ranges (low/high pc
zero? Could pick anything, but that seems the most obvious)
> 
> Thanks,
> - Dave

On Wed, Nov 28, 2018 at 9:47 AM Adrian Prantl <aprantl at apple.com>
wrote:
>
>
> > On Nov 28, 2018, at 9:40 AM, David Blaikie <dblaikie at
gmail.com> wrote:
> >
> > So I've been looking at a particular performance problem with
LLVM's
> symbolizer due to the use of ThinLTO, split DWARF, and split DWARF inlining
> info.
> >
> > This combination has a couple of problems:
> >
> > 1) it means multiple CUs in a single DWO, which isn't well
> defined/specified, and best avoided - so I'm working on fixing that
here
> (won't fix split DWARF+Full LTO) because we already don't use
cross-CU
> references in the split units (because there's no supported way to
express
> that in DWARF), so we clone/move any DIEs (like subprograms) referenced
> cross-CU into the CU that references them (eg: cross-CU inlining places the
> abstract subprogram definition for the inlined subroutine into the CU that
> has the inlining - rather than cross-CU referencing into the other CU)) -
> and in ThinLTO the only reason other units exist is to cross-CU
> optimize/inline, no code for imported CUs is ever emitted (except where
> it's been inlined) - so a ThinLTO compile has one primary unit, and
some
> other units it inlines from - so those other units never emit anything in
> the split unit, just a few DIEs in the skeleton unit if you're using
split
> DWARF inlining (or no unit at all if you aren't using that feature) -
so
> I'm working on making it so those units are non-split (rather than
having a
> degenerate/empty split unit)
> >
> > 2) symbolizer performance is hurt because whenever it sees a unit
> without ranges at the unit DIE, it assumes the producer just skipped those
> - and goes searching through the implementation DIEs (which may mean going
> over to the .dwo, or loading a whole .dwp) to see where their addresses
are.
> >
> > It's this second step that's a bit painfully unnecessary,
especially for
> a large DWP on a remote filesystem, etc.
> >
> > So, anyone have opinions on whether we should
> >
> > a) decide that a unit without ranges covers no ranges - and don't
do the
> search
>
> Are there compilers that do this ("forget" to emit ranges) that
we care to
> support with llvm-symbolizer?
>
I'm not specifically aware of any, though haven't gone looking.

>
> -- adrian
>
> >
> > b) emit zero-length ranges on any unit that has no code ranges
(low/high
> pc zero? Could pick anything, but that seems the most obvious)
> >
> > Thanks,
> > - Dave
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181128/0cf7b4b1/attachment.html>