llvm dev - Jul 2018 - 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!

Son Tuan Vu
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180712/32d589f2/attachment.html>

On 07/12/2018 10:19 AM, Son Tuan VU via llvm-dev wrote:
> 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?
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.
>
> 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.
Why is printing the IR before the verifier undesirable? It seems
desirable to me.

 -Hal
>
> Thanks for your help!
>
> Son Tuan Vu
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180712/627ae243/attachment.html>

> On Jul 12, 2018, at 18:25, Hal Finkel via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Why is printing the IR before the verifier undesirable? It seems desirable
to me.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180712/e04e3d92/attachment.html>

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.

Son Tuan Vu

On Thu, Jul 12, 2018 at 5:25 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>
> On 07/12/2018 10:19 AM, Son Tuan VU via llvm-dev wrote:
>
> 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?
>
>
> 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.
>
>
> 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.
>
>
> Why is printing the IR before the verifier undesirable? It seems desirable
> to me.
>
>  -Hal
>
>
> Thanks for your help!
>
> Son Tuan Vu
>
>
> _______________________________________________
> LLVM Developers mailing listllvm-dev at
lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180712/8798509a/attachment.html>

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

On Thu, Jul 12, 2018 at 11:19 PM Son Tuan VU via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> 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!
>
> Son Tuan Vu
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On 07/12/2018 12:43 PM, Chijun Sima via llvm-dev wrote:
> 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
>
> Best,
> Chijun Sima
>
> On Thu, Jul 12, 2018 at 11:19 PM Son Tuan VU via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> 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!
>>
>> Son Tuan Vu
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory