[llvm-dev] [RFC] Pass return status

Mehdi AMINI via llvm-dev llvm-dev at lists.llvm.org
Fri Jun 12 14:24:14 PDT 2020


On Thu, Jun 11, 2020 at 8:42 AM Serge Guelton via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi folks,
>
> Per the documentation[0], whenever an LLVM pass doesn't modify the IR it's
> run on, it
> should return `false`--it's okay to return `true` if no change happen,
> just less
> optimal. In the New PM area, this is generally translated into a
> `PreservedAnalyses::all()`.
>
> https://reviews.llvm.org/D80916 provides an `EXPENSIVE_CHECK` that
> computes a
> hash of the IR before and after the pass, and checks that any change is
> correctly reported. The hash is currently incomplete (on purpose, let's
> start
> small), but it turns out a dozen of passes do not satisfy that
> requirement.
>
> This could lead to various category of bugs (dangling references,
> inconsistent
> state, etc). This affects both New and Legacy PM, as passes tend to wrap
> functions
> that report their status.
>
> I wrote a bunch of patches for all failure detected by this check, as I
> cannot land the
> check now, it would break the buildbots :-) Any help to review the
> remaining
> ones [1] is appreciated.
>
> Once that check lands and we're relatively confident on the quality of the
> return status, some more optimizations could be triggered, like
> https://reviews.llvm.org/D80707.
>

Awesome feature! I am really fond of these pieces of infrastructure that
can defend against human mistakes and save countless hours of debugging
when subtle issues arise.

Thanks Serge,

-- 
Mehdi



>
>
> [0] https://llvm.org/docs/WritingAnLLVMPass.html#the-runonmodule-method
> [1] https://reviews.llvm.org/D81230
>     https://reviews.llvm.org/D81236
>     https://reviews.llvm.org/D81256
>     https://reviews.llvm.org/D81238
>     https://reviews.llvm.org/D81225
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200612/ee7c0c0a/attachment.html>


More information about the llvm-dev mailing list