llvm dev - Mar 2021 - How to get from "opt -O3" to "opt <a-single-pass>" with the new PM?

> On Feb 25, 2021, at 07:03, Mikael Holmén <mikael.holmen at
ericsson.com> wrote:
> 
> On Wed, 2021-02-24 at 11:25 -0800, Arthur Eubanks wrote:
>> There's no way to get a list of passes. Currently the name used to
>> specify a pass, e.g. "instcombine" in -passes=instcombine is
mostly a
>> one way street to creating the pass, it's hard to go backwards from
a
>> pass to the original name due to the implementation. This could be
>> fixed, but it'd be a fairly large change.
>> 
>> Personally I'd prefer an addition to
https://reviews.llvm.org/D86657
>> where we dump the IR on a crash to a file. Then with
-debug-pass-manager, we can see which pass caused the crash. Then use
llvm-reduce to reduce the IR, running only that one pass.
>> 
> 
> Ok. So more or less the tool we have is -print-before-all -debug-pass-
> manager and copy/paste the last input and rerun with the last
> interesting pass. -print-on-crash makes it a little bit more convenient
> when a pass crashes. I suppose this will work ok in many cases.
Unfortunately this won’t work when the problem is caused by state not captured
in LLVM IR. E.g. a pass could optimize the MemorySSA for a function and then the
optimized MemorySSA is used by a subsequent pass, which crashes because the
optimized MemorySSA enables an optimization. If you just use the IR before the
crash, the pass will use unoptimized MemorySSA and may not crash. There are
other analysis results that may expose similar effects.

I think we need a way to reduce the passes involved in such scenarios.

Cheers,
Florian

On Thu, 2021-02-25 at 10:25 +0000, Florian Hahn wrote:
> > On Feb 25, 2021, at 07:03, Mikael Holmén <
> > mikael.holmen at ericsson.com> wrote:
> > 
> > On Wed, 2021-02-24 at 11:25 -0800, Arthur Eubanks wrote:
> > > There's no way to get a list of passes. Currently the name
used
> > > to
> > > specify a pass, e.g. "instcombine" in
-passes=instcombine is
> > > mostly a
> > > one way street to creating the pass, it's hard to go
backwards
> > > from a
> > > pass to the original name due to the implementation. This could
> > > be
> > > fixed, but it'd be a fairly large change.
> > > 
> > > Personally I'd prefer an addition to 
> > >
https://protect2.fireeye.com/v1/url?k=b28a4060-ed117a79-b28a00fb-8682aaa22bc0-2fe31fd4ca0dd9ee&q=1&e=71cf8e51-b719-4c90-b79a-9aad4f1804c5&u=https%3A%2F%2Freviews.llvm.org%2FD86657
> > > where we dump the IR on a crash to a file. Then with -debug-pass-
> > > manager, we can see which pass caused the crash. Then use llvm-
> > > reduce to reduce the IR, running only that one pass.
> > > 
> > 
> > Ok. So more or less the tool we have is -print-before-all -debug-
> > pass-
> > manager and copy/paste the last input and rerun with the last
> > interesting pass. -print-on-crash makes it a little bit more
> > convenient
> > when a pass crashes. I suppose this will work ok in many cases.
> 
> Unfortunately this won’t work when the problem is caused by state not
> captured in LLVM IR. E.g. a pass could optimize the MemorySSA for a
> function and then the optimized MemorySSA is used by a subsequent
> pass, which crashes because the optimized MemorySSA enables an
> optimization. If you just use the IR before the crash, the pass will
> use unoptimized MemorySSA and may not crash. There are other analysis
> results that may expose similar effects.
> 
> I think we need a way to reduce the passes involved in such
> scenarios.
+1

This is what I tried to describe in the 

"Another case is when a number of passes is needed to make a certain
pass expose something interesting."

case.

Thanks,
Mikael
> 
> Cheers,
> Florian

Alright, I will try to come up with a nice way of reducing the list of
passes.

On Sat, Feb 27, 2021 at 12:33 AM Mikael Holmén <mikael.holmen at
ericsson.com>
wrote:
> On Thu, 2021-02-25 at 10:25 +0000, Florian Hahn wrote:
> > > On Feb 25, 2021, at 07:03, Mikael Holmén <
> > > mikael.holmen at ericsson.com> wrote:
> > >
> > > On Wed, 2021-02-24 at 11:25 -0800, Arthur Eubanks wrote:
> > > > There's no way to get a list of passes. Currently the
name used
> > > > to
> > > > specify a pass, e.g. "instcombine" in
-passes=instcombine is
> > > > mostly a
> > > > one way street to creating the pass, it's hard to go
backwards
> > > > from a
> > > > pass to the original name due to the implementation. This
could
> > > > be
> > > > fixed, but it'd be a fairly large change.
> > > >
> > > > Personally I'd prefer an addition to
> > > >
>
https://protect2.fireeye.com/v1/url?k=b28a4060-ed117a79-b28a00fb-8682aaa22bc0-2fe31fd4ca0dd9ee&q=1&e=71cf8e51-b719-4c90-b79a-9aad4f1804c5&u=https%3A%2F%2Freviews.llvm.org%2FD86657
> > > > where we dump the IR on a crash to a file. Then with
-debug-pass-
> > > > manager, we can see which pass caused the crash. Then use
llvm-
> > > > reduce to reduce the IR, running only that one pass.
> > > >
> > >
> > > Ok. So more or less the tool we have is -print-before-all -debug-
> > > pass-
> > > manager and copy/paste the last input and rerun with the last
> > > interesting pass. -print-on-crash makes it a little bit more
> > > convenient
> > > when a pass crashes. I suppose this will work ok in many cases.
> >
> > Unfortunately this won’t work when the problem is caused by state not
> > captured in LLVM IR. E.g. a pass could optimize the MemorySSA for a
> > function and then the optimized MemorySSA is used by a subsequent
> > pass, which crashes because the optimized MemorySSA enables an
> > optimization. If you just use the IR before the crash, the pass will
> > use unoptimized MemorySSA and may not crash. There are other analysis
> > results that may expose similar effects.
> >
> > I think we need a way to reduce the passes involved in such
> > scenarios.
>
> +1
>
> This is what I tried to describe in the
>
> "Another case is when a number of passes is needed to make a certain
> pass expose something interesting."
>
> case.
>
> Thanks,
> Mikael
> >
> > Cheers,
> > Florian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210301/2c6a4554/attachment.html>