Should Verifier be an analysis?

Hello all,

I came across the code of Verifier, and see that it doesn’t modify the IR at all. Why it is not considered as an analysis pass?

Actually, this will have impact on debugify-each and print-before/after-all: we are not supposed to print/debugify Verifier pass, but since Verifier is declared as a transformation (well, a non-analysis) pass, we actually do print/debugify it.

Thanks for your help!

It does not analyze the IR for the use of other transformations or analysis passes. It does, in a sense, transform the IR: Either it does nothing, or, it deletes it all. Why is printing the IR before the verifier undesirable? It seems desirable to me. -Hal

I for one have always found this to be incredibly annoying. It just adds a massive amount of noise to the debugging experience when viewing -print-after-all and searching for where some specific transform happened

-Matt

Hi Hal,

Thanks for your reply. I thought that Verifier does not modify the IR, that’s why I said that printing the IR after the Verifier was not worth it. However, this is a problem for DebugifyEach. In a nutshell, DebugifyEach has 2 parts: it first inserts synthetic debug info to the IR, so it creates a DICompileUnit, DILocations, DIVariables, and so on… Then the pass to be debugified gets executed, and finally comes the second part of DebugifyEach, which verifies the inserted debug info, dumps the statistics, and removes these debug info. The problem is, Verifier registers the DICompileUnit in run(), then checks if the DICompileUnit is still there in doFinalization(). Unfortunately, the second part of DebugifyEach already removed that DICompileUnit…

If this is only a problem for DebugifyEach, I can handle Verifier specially. But as Matt points out, it is quite annoying to print the IR out after Verifier, which most of the time do not modify the IR at all.

Hi,

I am wondering whether it is feasible to preserve the DominatorTree
which is recalculated in the Verifier by making Verifier into an
analysis. This recalculation actually consumes an approximately 7% of
the time used by the whole DominatorTree related calculations when
optimizing SQLite with opt -O3.

Best,
Chijun Sima

This I can definitely understand, but to this end, maybe we should have a setup where -print-after-all just doesn’t reprint IR if the previous pass didn’t change anything? Â -Hal

Hi,

I am wondering whether it is feasible to preserve the DominatorTree
which is recalculated in the Verifier by making Verifier into an
analysis. This recalculation actually consumes an approximately 7% of
the time used by the whole DominatorTree related calculations when
optimizing SQLite with opt -O3.

The verifier itself should not be invalidating the DT. It has this:

struct VerifierLegacyPass : public FunctionPass {
...
void getAnalysisUsage(AnalysisUsage &AU) const override {
AU.setPreservesAll();

I assume that the problem is that other passes are invalidating the DT
in between verifier runs?

Are you benchmarking with asserts enabled? I was under the impression
that we skipped the verifier runs in release builds with asserts disabled.

-Hal

It can be helpful to see what passes actually ran, even if they didn't change anything. Maybe we could have another option, like -print-after-changes?

-Krzysztof

This I can definitely understand, but to this end, maybe we should
have a setup where -print-after-all just doesn't reprint IR if the
previous pass didn't change anything?

It can be helpful to see what passes actually ran, even if they didn't
change anything. Maybe we could have another option, like
-print-after-changes?

I agree. What I had in mind was that the pass name itself would still
print, but we'd print "[unchanged]", or similar, instead of the IR in
cases where the IR didn't change. I'd also be happy with a separate
option (which we'd need anyway, especially because sometimes passes
incorrectly claim not to have changed the IR, and that might be the
problem you're debugging).

-Hal

We already have -debug-pass=Structure or =Executions

Thanks for your reply.

I found I happened to switch assertions on when benchmarking. But, the
Verifier still runs under Release+without assertions and still
consumes an approximately 7% of the time used by the whole
DominatorTree related calculations when optimizing SQLite with opt
-O3.

The verifier doesn't invalidate DT, it just construct one explicitly
as in https://github.com/llvm-mirror/llvm/blob/master/lib/IR/Verifier.cpp#L325-L332
Preserving the freshly calculated DomTree would be nice.