SROA on amalgamated sqlite source

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

Here is the full results file.

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

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.

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?