(original) (raw)

On Thu, 2021-02-25 at 10:25 +0000, Florian Hahn wrote:
\> > On Feb 25, 2021, at 07:03, Mikael Holmén <
\> > mikael.holmen@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