[llvm-dev] [SROA][DebugInfo][GSoC] Testing SROA on amalgamated sqlite source

Anast Gramm via llvm-dev llvm-dev at lists.llvm.org
Wed May 30 08:37:06 PDT 2018


Introduction
============

  `SROA' is an early stage pass running at the very beginning of the
  pipeline in `-O{1,2,3}'. Greg Bedwell's report from his DExTer tool
  shows SROA on function as one of the major culprits of Debug Info
  loss.

  With debugify-each partially done I tried testing this on the
  amalgamated sqlite source.

  The steps are as follows:
  ,----
  | # generate IR file without debug info and optnone
  | clang -O0 -Xclang -disable-O0-optnone -S -emit-llvm sqlite3.c -o sqlite
  | 
  | # run opt
  | opt -sroa -debugify-each sqlite -disable-output 2> results
  `----


Results
=======

  [Here] is the full results file.

  The results were gather by `grep -c`'ing the results file according to
  the error's message.

   SROA runs | FAIL | PASS | empty DebugLoc | Missing line warnings 
  -----------|------|------|----------------|-----------------------
        1978 | 1100 |  878 |           5214 |                 75166 

  What's worth noticing is that the only error that SROA produces is
  that of empty debug locations. It does not report any missing
  DILocalVariables or llvm.dbg.value intrinsics. Thus all of the 1100
  SROA runs that failed are due to empty debug locations.

  Also, while skimming through the results file I noticed that the
  instructions with missing DL were `phi' instructions. To confirm this
  I did:

    $ grep "ERROR: Instruction" results | grep phi -c

  witch gives us a result of `5214' and this means that all the
  instructions with missing Debug Loc are `phi' instructions.


[Here] https://gramanas.github.io/sroa-results.csv


Conclusion
==========

  This implies SROA does a pretty good job of preserving debug values.

  The DExTer results are not in line with what I've found though. This
  might be for a number of reasons. E.g. it could score so low due to
  the DebugLoc loss. Also debugify doesn't test the backend so it's
  going to detect a narrower set of issues.

  Do you have any ideas as to why this happens? Can you confirm the
  results?

  @Adrian, @Greg any thoughts would be appreciated!


More information about the llvm-dev mailing list