summaryrefslogtreecommitdiffstats
path: root/llvm/tools/bugpoint
Commit message (Collapse)AuthorAgeFilesLines
* Update compiler extension integration into the build systemserge-sans-paille2020-06-171-2/+1
| | | | | | | | | | | | The approach here is to create a new (empty) component, `Extensions', where all statically compiled extensions dynamically register their dependencies. That way we're more natively compatible with LLVMBuild and llvm-config. Fixes: https://bugs.llvm.org/show_bug.cgi?id=44870 Differential Revision: https://reviews.llvm.org/D78192 (cherry picked from commit 8f766e382b77eef3102798b49e087d1e4804b984)
* Generalize the pass registration mechanism used by Polly to any third-party toolserge_sans_paille2020-01-022-15/+13
| | | | | | | | | | | | | | | | | | | | | | | | There's quite a lot of references to Polly in the LLVM CMake codebase. However the registration pattern used by Polly could be useful to other external projects: thanks to that mechanism it would be possible to develop LLVM extension without touching the LLVM code base. This patch has two effects: 1. Remove all code specific to Polly in the llvm/clang codebase, replaicing it with a generic mechanism 2. Provide a generic mechanism to register compiler extensions. A compiler extension is similar to a pass plugin, with the notable difference that the compiler extension can be configured to be built dynamically (like plugins) or statically (like regular passes). As a result, people willing to add extra passes to clang/opt can do it using a separate code repo, but still have their pass be linked in clang/opt as built-in passes. Differential Revision: https://reviews.llvm.org/D61446
* [Bugpoint] Do not create illegal function attribute combosDavid Greene2019-12-161-0/+5
| | | | | | | If a function requires optnone to trigger a crash, it must also have noline, otherwise it will fail a verifier check. Differential revision: https://reviews.llvm.org/D69522
* bugpoint: Add option to disable attribute removalMatt Arsenault2019-11-191-23/+29
| | | | | | | This takes a long time and never reduces anything useful for me (e.g. I've been waiting for 3 hours on a testcase and it hasn't found any attributes to remove yet). This should probably start by assuming no attributes matter, and adding back.
* Sink all InitializePasses.h includesReid Kleckner2019-11-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This file lists every pass in LLVM, and is included by Pass.h, which is very popular. Every time we add, remove, or rename a pass in LLVM, it caused lots of recompilation. I found this fact by looking at this table, which is sorted by the number of times a file was changed over the last 100,000 git commits multiplied by the number of object files that depend on it in the current checkout: recompiles touches affected_files header 342380 95 3604 llvm/include/llvm/ADT/STLExtras.h 314730 234 1345 llvm/include/llvm/InitializePasses.h 307036 118 2602 llvm/include/llvm/ADT/APInt.h 213049 59 3611 llvm/include/llvm/Support/MathExtras.h 170422 47 3626 llvm/include/llvm/Support/Compiler.h 162225 45 3605 llvm/include/llvm/ADT/Optional.h 158319 63 2513 llvm/include/llvm/ADT/Triple.h 140322 39 3598 llvm/include/llvm/ADT/StringRef.h 137647 59 2333 llvm/include/llvm/Support/Error.h 131619 73 1803 llvm/include/llvm/Support/FileSystem.h Before this change, touching InitializePasses.h would cause 1345 files to recompile. After this change, touching it only causes 550 compiles in an incremental rebuild. Reviewers: bkramer, asbirlea, bollu, jdoerfert Differential Revision: https://reviews.llvm.org/D70211
* [NFC] Add SUPPORT_PLUGINS to add_llvm_executable()David Tenty2019-11-061-3/+1
| | | | | | | | | | | | | | | | | | | Summary: this allows us to move logic about when it is appropriate set LLVM_NO_DEAD_STRIP out of each tool and into add_llvm_executable, which will enable future platform specific handling. This is a follow on to the reverted D69356 Reviewers: hubert.reinterpretcast, beanz, lhames Reviewed By: beanz Subscribers: mgorny, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D69638
* Revert "[NFC] Rename LLVM_NO_DEAD_STRIP"David Tenty2019-10-301-1/+1
| | | | This reverts commit 11c2a85db8849db1a5907e80d9966592248ef825.
* [bugpoint] Reduce metadata that does not contribute to crash.Florian Hahn2019-10-301-1/+89
| | | | | | | | | | | | | | Add a new reducer that drops metadata that does not contribute to the crash from instructions. It adjusts the metadata.ll test case, as now also the instruction level metadata will get dropped. Reviewers: davide, reames, modocache Reviewed By: reames Differential Revision: https://reviews.llvm.org/D69234
* [bugpoint] Try to reduce passes after reducing everything.Florian Hahn2019-10-291-1/+15
| | | | | | | | | | | | | | | | In some cases, we fail to reduce the pass list earlier because of complex pass dependencies, but we can reduce it after we simplified the reproducer. An example of that is PR43474, which can limit the crash to -loop-interchange. Adding a test case would require at least 2 interacting Loop passes I think. Reviewers: davide, reames, modocache Reviewed By: reames Differential Revision: https://reviews.llvm.org/D69236
* [NFC] Rename LLVM_NO_DEAD_STRIPDavid Tenty2019-10-251-1/+1
| | | | | | | | | | | | | | | | | Summary: The variable LLVM_NO_DEAD_STRIP is set in LLVM cmake files when building executables that might make use of plugins .The name of the variable does not convey the actual intended usage (i.e. for use with tools that have plugins), just what the eventual effect of setting in on some (i.e. not garbage collecting unused symbols). This patch renames it to LLVM_SUPPORT_PLUGINS to convey the intended usage, which will allow subsequent patches to add behavior to support that in different ways without confusion about whether it will do on, for example, non-gnu platforms. Reviewers: hubert.reinterpretcast, stevewan Reviewed By: stevewan Subscribers: cfe-commits, mgorny, llvm-commits Tags: #llvm, #clang Differential Revision: https://reviews.llvm.org/D69356
* [bugpoint] Update runPasses to take ArrayRef instead of a pointer (NFC)Florian Hahn2019-09-303-12/+8
| | | | | | | | | | | | | This makes it slightly easier to pass extra arguments to runPasses and simplifies the code slightly. Reviewers: efriedma, bogner, dblaikie, diegotf, hiraditya Reviewed By: dblaikie, hiraditya Differential Revision: https://reviews.llvm.org/D68228 llvm-svn: 373265
* [bugpoint] Add support for -Oz and properly enable -Os.Florian Hahn2019-09-171-12/+34
| | | | | | | | | | | | | | | | | This patch adds -Oz as option and also properly enables support for -Os. Currently, the existing check for -Os is dead, because the enclosing if only checks of O1, O2 and O3. There is still a difference between the -Oz pipeline compared to opt, but I have not been able to track that down yet. Reviewers: bogner, sebpop, efriedma Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D67593 llvm-svn: 372079
* Bugpoint: Remove some unnecessary c_str conversions on the journey to StringRefDavid Blaikie2019-09-141-8/+8
| | | | llvm-svn: 371910
* Rename F_{None,Text,Append} to OF_{None,Text,Append}. NFCFangrui Song2019-08-051-1/+1
| | | | | | F_{None,Text,Append} are kept for compatibility since r334221. llvm-svn: 367800
* [Bugpoint] fix another use-after-move. NFCNick Desaulniers2019-05-311-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: This was flagged in https://www.viva64.com/en/b/0629/ under "Snippet No. 7". These statements are order independent, short of the use-after-move. Reviewers: echristo, srhines, RKSimon Reviewed By: RKSimon Subscribers: dblaikie, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62114 llvm-svn: 362267
* Fix BUILD_SHARED_LIBS builds after r361567Daniel Sanders2019-05-241-0/+2
| | | | | | Also fixed a comment I noticed while debugging this build llvm-svn: 361591
* Break false dependencies on target librariesDaniel Sanders2019-05-231-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: For the most part this consists of replacing ${LLVM_TARGETS_TO_BUILD} with some combination of AllTargets* so that they depend on specific components of a target backend rather than all of it. The overall effect of this is that, for example, tools like opt no longer falsely depend on the disassembler, while tools like llvm-ar no longer depend on the code generator. There's a couple quirks to point out here: * AllTargetsCodeGens is a bit more prevalent than expected. Tools like dsymutil seem to need it which I was surprised by. * llvm-xray linked to all the backends but doesn't seem to need any of them. It builds and passes the tests so that seems to be correct. * I left gold out as it's not built when binutils is not available so I'm unable to test it Reviewers: bogner, JDevlieghere Reviewed By: bogner Subscribers: mehdi_amini, mgorny, steven_wu, dexonsmith, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62331 llvm-svn: 361567
* [Bugpoint] fix use-after-move. NFCNick Desaulniers2019-05-211-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This was flagged in https://www.viva64.com/en/b/0629/ under "Snippet No. 6". Note that author also states: "Note that the loop doesn't actually execute at all." This is not true, but the author can be forgiven; there's two distinct variables with very similar identifiers: MiscompiledFunctions MisCompFunctions Reviewers: echristo, srhines, RKSimon Reviewed By: RKSimon Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62113 llvm-svn: 361279
* [opaque pointer types] Pass value type to LoadInst creation.James Y Knight2019-02-011-1/+2
| | | | | | | | | This cleans up all LoadInst creation in LLVM to explicitly pass the value type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57172 llvm-svn: 352911
* [opaque pointer types] Pass function types to CallInst creation.James Y Knight2019-02-011-2/+2
| | | | | | | | | This cleans up all CallInst creation in LLVM to explicitly pass a function type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57170 llvm-svn: 352909
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-02-011-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc doesn't choke on it, hopefully. Original Message: The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352827
* Revert "[opaque pointer types] Add a FunctionCallee wrapper type, and use it."James Y Knight2019-01-311-3/+2
| | | | | | | | | This reverts commit f47d6b38c7a61d50db4566b02719de05492dcef1 (r352791). Seems to run into compilation failures with GCC (but not clang, where I tested it). Reverting while I investigate. llvm-svn: 352800
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-01-311-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352791
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1913-52/+39
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [bugpoint][PR29027] Reduce function attributesBrian Gesiak2018-12-191-0/+92
| | | | | | | | | | | | | | | | | | | | | Summary: In addition to reducing the functions in an LLVM module, bugpoint now reduces the function attributes associated with each of the remaining functions. To test this, add a -bugpoint-crashfuncattr test pass, which crashes if a function in the module has a "bugpoint-crash" attribute. A test case demonstrates that the IR is reduced to just that one attribute. Reviewers: MatzeB, silvas, davide, reames Reviewed By: reames Subscribers: reames, llvm-commits Differential Revision: https://reviews.llvm.org/D55216 llvm-svn: 349601
* [bugpoint] Find 'opt', etc., in bugpoint directoryBrian Gesiak2018-12-104-65/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When bugpoint attempts to find the other executables it needs to run, such as `opt` or `clang`, it tries searching the user's PATH. However, in many cases, the 'bugpoint' executable is part of an LLVM build, and the 'opt' executable it's looking for is in that same directory. Many LLVM tools handle this case by using the `Paths` parameter of `llvm::sys::findProgramByName`, passing the parent path of the currently running executable. Do this same thing for bugpoint. However, to preserve the current behavior exactly, first search the user's PATH, and then search for 'opt' in the directory containing 'bugpoint'. Test Plan: `check-llvm`. Many of the existing bugpoint tests no longer need to use the `--opt-command` option as a result of these changes. Reviewers: MatzeB, silvas, davide Reviewed By: MatzeB, davide Subscribers: davide, llvm-commits Differential Revision: https://reviews.llvm.org/D54884 llvm-svn: 348734
* [TI removal] Make `getTerminator()` return a generic `Instruction`.Chandler Carruth2018-10-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | This removes the primary remaining API producing `TerminatorInst` which will reduce the rate at which code is introduced trying to use it and generally make it much easier to remove the remaining APIs across the codebase. Also clean up some of the stragglers that the previous mechanical update of variables missed. Users of LLVM and out-of-tree code generally will need to update any explicit variable types to handle this. Replacing `TerminatorInst` with `Instruction` (or `auto`) almost always works. Most of these edits were made in prior commits using the perl one-liner: ``` perl -i -ple 's/TerminatorInst(\b.* = .*getTerminator\(\))/Instruction\1/g' ``` This also my break some rare use cases where people overload for both `Instruction` and `TerminatorInst`, but these should be easily fixed by removing the `TerminatorInst` overload. llvm-svn: 344504
* [bugpoint] Revert r318459Don Hinton2018-09-181-8/+14
| | | | | | | | Summary: Revert r318459 which introduced a TempFile scoping bug. Differential Revision: https://reviews.llvm.org/D51836 llvm-svn: 342503
* [IR] Replace `isa<TerminatorInst>` with `isTerminator()`.Chandler Carruth2018-08-261-3/+3
| | | | | | | | | | | | This is a bit awkward in a handful of places where we didn't even have an instruction and now we have to see if we can build one. But on the whole, this seems like a win and at worst a reasonable cost for removing `TerminatorInst`. All of this is part of the removal of `TerminatorInst` from the `Instruction` type hierarchy. llvm-svn: 340701
* Refactor ExecuteAndWait to take StringRefs.Zachary Turner2018-06-122-101/+88
| | | | | | | | | | | | | | | | | | | This simplifies some code which had StringRefs to begin with, and makes other code more complicated which had const char* to begin with. In the end, I think this makes for a more idiomatic and platform agnostic API. Not all platforms launch process with null terminated c-string arrays for the environment pointer and argv, but the api was designed that way because it allowed easy pass-through for posix-based platforms. There's a little additional overhead now since on posix based platforms we'll be takign StringRefs which were constructed from null terminated strings and then copying them to null terminate them again, but from a readability and usability standpoint of the API user, I think this API signature is strictly better. llvm-svn: 334518
* Move Analysis/Utils/Local.h back to TransformsDavid Blaikie2018-06-041-1/+1
| | | | | | | | | | Review feedback from r328165. Split out just the one function from the file that's used by Analysis. (As chandlerc pointed out, the original change only moved the header and not the implementation anyway - which was fine for the one function that was used (since it's a template/inlined in the header) but not in general) llvm-svn: 333954
* Rename DEBUG macro to LLVM_DEBUG.Nicola Zaghen2018-05-143-33/+34
| | | | | | | | | | | | | | | | The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM - Manual change to APInt - Manually chage DOCS as regex doesn't match it. In the transition period the DEBUG() macro is still present and aliased to the LLVM_DEBUG() one. Differential Revision: https://reviews.llvm.org/D43624 llvm-svn: 332240
* Remove @brief commands from doxygen comments, too.Adrian Prantl2018-05-011-1/+1
| | | | | | | | | | | | | | | | | This is a follow-up to r331272. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done https://reviews.llvm.org/D46290 llvm-svn: 331275
* IWYU for llvm-config.h in llvm, additions.Nico Weber2018-04-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See r331124 for how I made a list of files missing the include. I then ran this Python script: for f in open('filelist.txt'): f = f.strip() fl = open(f).readlines() found = False for i in xrange(len(fl)): p = '#include "llvm/' if not fl[i].startswith(p): continue if fl[i][len(p):] > 'Config': fl.insert(i, '#include "llvm/Config/llvm-config.h"\n') found = True break if not found: print 'not found', f else: open(f, 'w').write(''.join(fl)) and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p` and tried to fix include ordering and whatnot. No intended behavior change. llvm-svn: 331184
* s/LLVM_ON_WIN32/_WIN32/, llvmNico Weber2018-04-291-1/+1
| | | | | | | | | | | | | | LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the default macro instead of a reinvented one. See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev. No intended behavior change. This moves over all uses of the macro, but doesn't remove the definition of it in (llvm-)config.h yet. llvm-svn: 331127
* [bugpoint] Fix crash when testing for miscompilation.Rafael Espindola2018-04-244-12/+15
| | | | | | | | | | | Method BugDriver::performFinalCleanups(...) would delete Module object it worked on, which was also deleted by its caller (e.g. TestCodeGenerator(...)). Changed the code to avoid double delete and make Module ownership slightly clearer. Patch by Andrzej Janik. llvm-svn: 330763
* Link to AggressiveInstCombine in a few places. Unbreaks build for me.Roman Lebedev2018-04-241-0/+1
| | | | | | | | | | | | /usr/local/bin/ld.lld: error: undefined symbol: llvm::createAggressiveInstCombinerPass() >>> referenced by cc1_main.cpp >>> tools/clang/tools/driver/CMakeFiles/clang.dir/cc1_main.cpp.o:(_GLOBAL__sub_I_cc1_main.cpp) And so on The bot coverage is clearly missing. llvm-svn: 330693
* [AggressiveInstCombine] Add library initializer routine for ↵Craig Topper2018-04-241-0/+1
| | | | | | | | AggressiveInstCombine library. Use it in bugpoint and llvm-opt-fuzzer to match regular InstCombine. This should make aggressive instcombine usable with these tools. llvm-svn: 330663
* Define InitLLVM to do common initialization all at once.Rui Ueyama2018-04-131-4/+2
| | | | | | | | | | | We have a few functions that virtually all command wants to run on process startup/shutdown. This patch adds InitLLVM class to do that all at once, so that we don't need to copy-n-paste boilerplate code to each llvm command's main() function. Differential Revision: https://reviews.llvm.org/D45602 llvm-svn: 330046
* Fix a couple of layering violations in TransformsDavid Blaikie2018-03-211-1/+1
| | | | | | | | | | | | | Remove #include of Transforms/Scalar.h from Transform/Utils to fix layering. Transforms depends on Transforms/Utils, not the other way around. So remove the header and the "createStripGCRelocatesPass" function declaration (& definition) that is unused and motivated this dependency. Move Transforms/Utils/Local.h into Analysis because it's used by Analysis/MemoryBuiltins.cpp. llvm-svn: 328165
* Change the BugDriver to store the current module with std::unique_ptr.Rafael Espindola2018-02-148-207/+185
| | | | | | | | | While there, change a bunch of helper functions to take references to avoid adding calls to get(). This should conclude the bugpoint yak shaving. llvm-svn: 325177
* Use std::uniue_ptr. NFC.Rafael Espindola2018-02-141-4/+4
| | | | llvm-svn: 325176
* Use std::unique_ptr. NFC.Rafael Espindola2018-02-141-12/+6
| | | | llvm-svn: 325174
* Use std::unique_ptr. NFC.Rafael Espindola2018-02-141-6/+5
| | | | llvm-svn: 325173
* Use std::unique_ptr. NFC.Rafael Espindola2018-02-141-4/+4
| | | | llvm-svn: 325172
* Use std::unique_ptr. NFC.Rafael Espindola2018-02-141-4/+3
| | | | llvm-svn: 325170
* Use std::unique_ptr. NFC.Rafael Espindola2018-02-141-4/+4
| | | | llvm-svn: 325167
* Use std::unique_ptr. NFC.Rafael Espindola2018-02-141-6/+5
| | | | llvm-svn: 325165
* Use std::unique_ptr. NFC.Rafael Espindola2018-02-141-9/+5
| | | | llvm-svn: 325164
* Use std::unique_ptr. NFC.Rafael Espindola2018-02-141-7/+5
| | | | llvm-svn: 325163
OpenPOWER on IntegriCloud