[llvm-dev] Sanitizers + New Pass Manager
Fedor Sergeev via llvm-dev
llvm-dev at lists.llvm.org
Thu May 14 03:13:30 PDT 2020
On 5/14/20 5:33 AM, Arthur Eubanks via llvm-dev wrote:
> > 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)?
While trying newPM with inliner turned off on O1 is fine and probably a
right approach on digging into the cause of the failure,
actually changing Ox to be that different depending on sanitizer mode
seems to be a bad idea to me.
regards,
Fedor.
>
> On Wed, May 13, 2020 at 3:14 PM Johannes Doerfert
> <johannesdoerfert at gmail.com <mailto: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> <mailto: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> <mailto: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 <mailto: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 list
>>>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> _______________________________________________
> 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/20200514/b5c310c4/attachment.html>
More information about the llvm-dev
mailing list