llvm dev - Jun 2013 - [LLVMdev] [cfe-dev] Meaning of LLVM optimization levels

> after O1, sequential execution is a big impediment for optimizations, and
> keeping the debug information valid after so many transformations might
> pose a big penalty on the passes (time & memory). That was the whole
> idea of metadata being a second-class citizen.
I'm afraid I don't know much about how debug information is expressed,
so this idea may
be nonsense.

Is it possible for the debug information to mark all the instructions that arise
from a
language statement as coming from that statement, even though the instructions
may
be widely scattered? That in itself would be quite helpful. Instructions whose
effects
are used in the logic from more than one statement would have to be included
with
all those statement.

I felt the lack of something like this severely when digging out dozens of
compiler bugs
on Microsoft's Itanium compiler, over a decade ago. That processor
"naturally" mixed
instructions from many source statements, which prefigured this kind of problem.

I'm reasonably happy for debugging at high optimisation levels to be
primarily done
with a disassembly listing rather than source code, provided I can get some idea
of
which instructions come from which source statements, and which variables are
being
accessed. The absence of debug information at that level tends to require going
through an entire function figuring out what every instruction does, and how it
relates to the source, which is rather time-consuming.

thanks,

--
John Dallman

From: Renato Golin [mailto:renato.golin at linaro.org]
Sent: 07 June 2013 17:39
To: Dallman, John
Cc: LLVM Dev; Clang Dev
Subject: Re: [cfe-dev] Meaning of LLVM optimization levels

On 7 June 2013 13:53, Dallman, John <john.dallman at
siemens.com<mailto:john.dallman at siemens.com>> wrote:
It needs to be possible to debug code at any optimisation level.

Yes, I agree. But after O1, sequential execution is a big impediment for
optimizations, and keeping the debug information valid after so many
transformations might pose a big penalty on the passes (time & memory). That
was the whole idea of metadata being a second-class citizen.


Related to optimisation levels, it's quite helpful to have a way of
controlling
optimisation on a function-by-function level. This is very useful when
you're trying
to work out where in a file with many functions an optimiser problem is
happening;
it isn't foolproof, but it helps a lot.

There are already people working on that, and discussions on the list about this
very topic. I agree that it would be extremely helpful for debugging large
programs.

cheers,
--renato

-----------------
Siemens Industry Software Limited is a limited company registered in England and
Wales.
Registered number: 3476850.
Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey,
GU16 8QD.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130607/cc28921c/attachment.html>

On 7 June 2013 17:52, Dallman, John <john.dallman at siemens.com> wrote:
>  Is it possible for the debug information to mark all the instructions
> that arise from a
>
> language statement as coming from that statement, even though the
> instructions may
>
> be widely scattered?
>
I'm not aware Dwarf supports statements, but it does support line and
column information, so if the sources are accurate, you can get
"statements" but not as a compiler would recognize, just as a string.

Line information is normally passed along optimizations and inlining, and
this is why debugging at O2/O3 has the effect of jumping randomly through
steps in the debugger. But the interaction of the debugger and the core is
extremely complex: breakpoints don't break in the right place, you might
break on the wrong thread, or not break at all, stepping doesn't change
lines consistently, you might step out of a function without noticing, etc,
etc.

Even if LLVM (or any compiler) kept all the debug information intact, it
still wouldn't mean much for the debugger if it couldn't make heads or
tails of that information as the core would chug along at random
instructions.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130607/7832edbb/attachment.html>

On 7 June 2013 17:52, Dallman, John <john.dallman at siemens.com>
wrote:
> Is it possible for the debug information to mark all the instructions that
arise
> from a
> language statement as coming from that statement, even though the
instructions may
> be widely scattered?
Yes.
> Instructions whose effects 
> are used in the logic from more than one statement would have to be
included with
> all those statement.
Hmmm, that would be atypical.  You *can* produce legal DWARF to do that, but
it's a little unlikely that any debugger would understand what you meant.
Generally each instruction is associated with a single statement.

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Renato Golin
> I'm not aware Dwarf supports statements, but it does support line and
column
> information, so if the sources are accurate, you can get
"statements" but not as a
> compiler would recognize, just as a string.
DWARF actually doesn't support source *extents*, it assumes the compiler
will map each statement to a single (canonical) source location and associate
each instruction produced for that statement to the same source location.

DWARF "supports statements" in the sense that a compiler can flag an
instruction as an appropriate place to set a breakpoint for a given
statement, i.e. the statement whose canonical source location is
associated with that instruction.

--paulr