On 6/11/19 11:49 AM, David Greene wrote:> "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.
I certainly agree that integration with DebugCounters, or similar, would
be a useful enhancement. I think that this is especially true for
analysis results. I've done this several times manually in order to
narrow down a single problematic alias-analysis query result.
>
>> 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
> now?
>
>
>> 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
> itself.
You linked them with llvm-link? That can change the result because of
inlining, etc. I've also created wrapper scripts to link in other .ll
files, etc. but the problem is that, often, I don't know in which .ll
file is the miscompiled code. Maybe I should have automated this a long
time ago, but I've always ended up writing shell scripts to try to
iterate over all of the .ll files and run bugpoint on each one in turn
(linking in the remaining ones) to try to find the one being
miscompiled. One problem, of course, is that this scales poorly - a
binary search would be better.
Thanks again,
Hal
>
> 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).
>
> -David
--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory