[llvm-dev] Sanitizers + New Pass Manager

Wed May 13 19:33:31 PDT 2020

> Is it the case that with the legacy PM there is no inlining at either -O2
or -O3 and with newPM there is? Or is there something else going on?
Legacy PM inlines at -O2/-O3, new PM inlines at -O1/-O2/-O3. These cases
where inlining occurs also coincide with the test failure. I agree that
inlining itself isn't the issue, but it seems to contribute to the
stripping of lifetime intrinsics and thus the test failure.

ASan needs lifetime intrinsics to implement use-after-scope. It may just be
luck that the legacy PM's -O1 happens to not strip lifetime intrinsics
before ASan gets to them?

I tried moving the *San passes before inlining and now the tests that I was
having trouble with pass, but new tests that specifically test inlining
fail, so I think it's probably fairly important to run *San passes after
inlining. But I tried moving them right after inlining (before
SROA/something gets to optimize things out) and some TSan tests now fail. I
found out TSan expects to be run after pretty much all other passes so that
it can change any memset/memcpy intrinsics into just the normal function
call to memset()/memcpy(). But if we move TSan to be run before
InstCombine, then InstCombine will change calls to memset()/memcpy() back
to the intrinsics and the tests don't like that. I think it's reasonable to
treat all *San passes the same way, so I don't think putting ASan somewhere
different from TSan makes sense. But that means there's no good place to
put these sanitizers.

I feel like a lot of these sanitizer tests just happened to work at -O1
under the legacy PM. I think I'll try having the new PM not inline when any
sanitizers are enabled and see if I can keep the house of cards standing.
Or is it a bad idea to change the PM behavior based on the detection of
sanitizers, since sanitizers won't be testing the same code you'd get
without sanitizing (e.g. a lot of the inlining tests would lose a lot of
their value)?

On Wed, May 13, 2020 at 3:14 PM Johannes Doerfert <
johannesdoerfert at gmail.com> wrote:

>
> On 5/13/20 3:31 PM, David Blaikie via llvm-dev wrote:
>
> I believe it's meant to run after /some/ optimizations to make it a bit
> more efficient, while not so optimized that it misses opportunities to
> detect bugs - but I could be wrong there. I'll leave it up to other folks
> to chime in.
>
> I think that is right. The more transformations you run the more UB you
> can also "loose" as it is defined to something by the transformation.
>
> Lifetime markers are an example. Once removed, which is generally legal in
> IR, you cannot argue accesses after the end are UB.
>
>
> On Wed, May 13, 2020 at 1:04 PM Arthur Eubanks <aeubanks at google.com> <aeubanks at google.com> wrote:
>
>
> Just tested it out, that test does indeed fail under the old PM at -O3 and
> even at -O2.
>
> If the ASan pass runs after optimizations and is designed to detect
> undefined behavior at runtime, I don't see how it can be super reliable at
> higher optimization levels.
>
> On Wed, May 13, 2020 at 12:39 PM David Blaikie <dblaikie at gmail.com> <dblaikie at gmail.com> wrote:
>
>
> +some sanitizer/new pass manager folks
>
>
>
> On Wed, May 13, 2020 at 12:22 PM Arthur Eubanks via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
>
> Hi,
>
> I've been trying to burn down the remaining sanitizer failures under the
> new pass manager. Right now I'm stuck on some ASan tests.
>
> Some ASan tests run under -O1. There are a couple differences between
> the old and new pass managers under -O1, e.g. the old PM doesn't inline
> whereas the new PM does. The differences seem to cause some lifetime
> intrinsics to get stripped out (e.g. via SROA, InstCombine). It might be
> due to ASan specifically testing undefined behavior, and different
> optimizations run means different behavior. For a specific example,
> use-after-scope-dtor-order.cpp runs under -O1 and fails under the new PM
> because SROA strips out the lifetime intrinsics and by the time the ASan
> pass runs it doesn't find the lifetime intrinsics to add its own
> instrumentation.
>
>
> That, to me, sounds like a real bug in the optimizations/asan
> implementation if this choice fo optimizations makes the diagnosis go away.
> (is ASan able to diagnose the problem at -O3 (where I guess SROA and other
> things run) with the legacy pass manager?)
>
>
>
> What's the proper way to resolve this? Run the tests under -O0? Change
> the passes pipeline under the new PM when ASan (and maybe other sanitizers)
> is detected?
> _______________________________________________
> LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> _______________________________________________
> LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://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/20200513/418388fb/attachment-0001.html>