[llvm-dev] Bugpoint Redesign

David Greene via llvm-dev llvm-dev at lists.llvm.org
Tue Jun 11 09:49:11 PDT 2019

"Finkel, Hal J. via llvm-dev" <llvm-dev at lists.llvm.org> writes:

> One concern that I have is that, from personal experience, the ability
> for bugpoint to reduce the set of optimization passes applied in order
> to reproduce a bug is extremely helpful. I understand your desire to
> decouple the logic somewhat, and maybe there's some way to generalize
> that functionality by enabling simultaneous delta reduction on some
> secondary inputs (some of which may happen to be a pass list), but I'd
> like to see us somehow retain that capability to isolate the
> problematic set of transformations.

I wonder if this might be better as a separate tool.  The functionality
is defintely useful.  In fact I'd like to see it enhanced by using
DebugCounters when available.  This will require some smarts for
DebugCounters to either report themselves to the tool or for passes to
report their DebugCounter-ness.

> bugpoint currently has the ability to debug miscompiles by splitting
> the code into a "known good" set of functions (which is puts into a
> separate library) and the remainder of the code (which, in theory, is
> the smallest part of the code necessary to reproduce the bug). This
> has also proven useful in the past. Is this something you intend to
> keep?

Yes, this is also very useful and would fit in with whatever tool does
the pass reduction mentioned above.  The first step would be to find the
subset of code that is miscompiled.  The second would be to do pass
reduction (with use of DebugCounters) over that miscompiled piece of
code.  Isn't this how bugpoint basically operates in miscompile mode

> My largest set of problems with bugpoint has been that bugpoint's
> logic for doing things like loop extraction will themselves often
> crash, and also, there's no easy way to start with multiple input
> files (e.g., what you start with from a program with multiple source
> files).

I've always just generated .ll files and linked them manually before
starting the bugpoint process.  I'd think it would be straightforward to
have bugpoint/whatever take a set of input files and do the link step

One other aspect of bugpoint/whatever that will become more important
since flang is now an official project is the ability to specify a
linker to use.  Analyzing Fortran codes will require the tool to know
which Fortran compiler to link with since there is no standard Fortran
ABI or runtime interface.  The copiler used to link must be the same one
used to generate the IR.  When mixing Fortran and C/C++, the tool will
need to know to use the Fortran compiler to do the link (and also link
in the C/C++ runtimes).


More information about the llvm-dev mailing list