llvm dev - Jun 2018 - [GSoC][DebugInfo] SROA debug experience and dexter thoughts

Hello, this is a post I compiled to summarize my experience with SROA so far
and to let the community know the results of the project.

Next, I'll look at the InstCombine pass. I will try to fix as many missing
dbg.value
cases as possible. I will post another update as soon as I have results.

Thanks for taking a look!

Blog post:
https://gramanas.github.io/posts/sroa-debug-experience-and-dexter-thoughts/

And in plain text:

1 Introduction
=============
  The past weeks the efforts were focused around the Scalar Replacement
  of Aggregates pass. This is an early stage pass and thus the amount of
  debug info loss should be minimized cause it impacts the whole
  compiler a lot more.

  Our contribution has been to systematically show that IR-level
  invariants on debug info are being respected by SROA/mem2reg.

  The debugify pass with the newly implemented [debugify-each] option
  was the main tool used.


[debugify-each] https://reviews.llvm.org/D46525


2 Process
========
  - Run sroa through samples of IR
  ,----
  | opt -debugify -sroa -check-debugify {ir_file.ll}
  `----
  - When finding errors I created a reduced IR test case like [here] and
    [here].
  - Fix the failing tests


[here] https://reviews.llvm.org/D47097

[here] https://reviews.llvm.org/D47720


3 Results
========
  I made a [report] after ruining SROA on the amalgamated sqlite source.
  The results were a clear indication that SROA was doing it's job just
  fine and the little instructions without DebugLoc were produced from
  clang and it wasn't SROA/mem2reg's fault.

  After applying the above clang patches the results are even better.


[report]
https://gramanas.github.io/posts/sroa-on-amalgamated-sqlite-source/


4 Comparing the results to [dexter] ones
=======================================
  Dexter scored SROA low.

  As Greg (dexter's creator) mentions the dexter results don't have to
  indicate that there is some kind of bug:

        My standard disclaimer with all results from this tool is
        that a non-perfect debugging experience score is not
        necessarily indicative of something wrong, but should be
        looked at in conjunction with all the other factors such
        as what the pass is trying to achieve optimization-wise.

  And such is the case with SROA.

  A [bug report] has been filed explaining the problem.

  Basically after running SROA/mem2reg the optimizations will at many
  cases result in weird stepping behavior in the debugger. This is
  normal since that's the whole point of passes like SROA and LICM: to
  reduce the instructions by optimizing aggregates and loops.

  This is bad from the debug perspective and thus scores low on dexter.


[dexter]
https://llvm.org/devmtg/2018-04/slides/Bedwell-Measuring_the_User_Debugging_Experience.pdf

[bug report] https://bugs.llvm.org/show_bug.cgi?id=37682

4.1 Optimized vs unoptimized debugging
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  An optimizers job is to make the code execute faster on the given
  machine. This comes at the cost of modifying the code to a point that
  it no longer resembles the source material. Thus we rely on the
  descriptive power of the standard that is used to encode DI.

  Passes that move code around or shorten the execution paths like SROA
  and LICM should go to great lengths to preserve the debug intrinsics
  that correspond the the name and value of the variables. It would be
  an unrealistic goal to try and keep the stepping behavior inside a
  debugger intact after running such passes.

  Instead, different optimization methods can be used when debugging is a
  high priority. Ones that don't move code around as much and of course
  result in longer execution times, but what they lose in speed they
  give back with a more robust debug experience.


5 Conclusion
===========
  SROA does a very good job preserving all the important Debug
  Information that it's given. On the other hand it significantly
  impacts the debug user experience but there is nothing that can be
  done about it as this is the nature of the transformation.

Thanks for this writeup!

  Passes that move code around or shorten the execution paths like
SROA
>   and LICM should go to great lengths to preserve the debug intrinsics
>   that correspond the the name and value of the variables. It would be
>   an unrealistic goal to try and keep the stepping behavior inside a
>   debugger intact after running such passes.
>
>   Instead, different optimization methods can be used when debugging is a
>   high priority. Ones that don't move code around as much and of course
>   result in longer execution times, but what they lose in speed they
>   give back with a more robust debug experience.
>
>
Absolutely.  I think we should make -O2/-O3 as debugable as possible
without sacrificing performance, and then whatever is left becomes a prime
candidate for assessing whether we can get away with turning it off or
turning it down for -Og.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180608/9056cb2e/attachment.html>