summaryrefslogtreecommitdiffstats
path: root/llvm/lib/FuzzMutate
Commit message (Collapse)AuthorAgeFilesLines
* [cmake] Explicitly mark libraries defined in lib/ as "Component Libraries"Tom Stellard2019-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Most libraries are defined in the lib/ directory but there are also a few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining "Component Libraries" as libraries defined in lib/ that may be included in libLLVM.so. Explicitly marking the libraries in lib/ as component libraries allows us to remove some fragile checks that attempt to differentiate between lib/ libraries and tools/ libraires: 1. In tools/llvm-shlib, because llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of all libraries defined in the whole project, there was custom code needed to filter out libraries defined in tools/, none of which should be included in libLLVM.so. This code assumed that any library defined as static was from lib/ and everything else should be excluded. With this change, llvm_map_components_to_libnames(LIB_NAMES, "all") only returns libraries that have been added to the LLVM_COMPONENT_LIBS global cmake property, so this custom filtering logic can be removed. Doing this also fixes the build with BUILD_SHARED_LIBS=ON and LLVM_BUILD_LLVM_DYLIB=ON. 2. There was some code in llvm_add_library that assumed that libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or ARG_LINK_COMPONENTS set. This is only true because libraries defined lib lib/ use LLVMBuild.txt and don't set these values. This code has been fixed now to check if the library has been explicitly marked as a component library, which should now make it easier to remove LLVMBuild at some point in the future. I have tested this patch on Windows, MacOS and Linux with release builds and the following combinations of CMake options: - "" (No options) - -DLLVM_BUILD_LLVM_DYLIB=ON - -DLLVM_LINK_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON Reviewers: beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70179
* [llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-151-1/+1
| | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. llvm-svn: 369013
* [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
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-196-24/+18
| | | | | | | | | | | | | | | | | 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
* [New PM] Introducing PassInstrumentation frameworkFedor Sergeev2018-09-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pass Execution Instrumentation interface enables customizable instrumentation of pass execution, as per "RFC: Pass Execution Instrumentation interface" posted 06/07/2018 on llvm-dev@ The intent is to provide a common machinery to implement all the pass-execution-debugging features like print-before/after, opt-bisect, time-passes etc. Here we get a basic implementation consisting of: * PassInstrumentationCallbacks class that handles registration of callbacks and access to them. * PassInstrumentation class that handles instrumentation-point interfaces that call into PassInstrumentationCallbacks. * Callbacks accept StringRef which is just a name of the Pass right now. There were some ideas to pass an opaque wrapper for the pointer to pass instance, however it appears that pointer does not actually identify the instance (adaptors and managers might have the same address with the pass they govern). Hence it was decided to go simple for now and then later decide on what the proper mental model of identifying a "pass in a phase of pipeline" is. * Callbacks accept llvm::Any serving as a wrapper for const IRUnit*, to remove direct dependencies on different IRUnits (e.g. Analyses). * PassInstrumentationAnalysis analysis is explicitly requested from PassManager through usual AnalysisManager::getResult. All pass managers were updated to run that to get PassInstrumentation object for instrumentation calls. * Using tuples/index_sequence getAnalysisResult helper to extract generic AnalysisManager's extra args out of a generic PassManager's extra args. This is the only way I was able to explicitly run getResult for PassInstrumentationAnalysis out of a generic code like PassManager::run or RepeatedPass::run. TODO: Upon lengthy discussions we agreed to accept this as an initial implementation and then get rid of getAnalysisResult by improving RepeatedPass implementation. * PassBuilder takes PassInstrumentationCallbacks object to pass it further into PassInstrumentationAnalysis. Callbacks registration should be performed directly through PassInstrumentationCallbacks. * new-pm tests updated to account for PassInstrumentationAnalysis being run * Added PassInstrumentation tests to PassBuilderCallbacks unit tests. Other unit tests updated with registration of the now-required PassInstrumentationAnalysis. Made getName helper to return std::string (instead of StringRef initially) to fix asan builtbot failures on CGSCC tests. Reviewers: chandlerc, philip.pfaffe Differential Revision: https://reviews.llvm.org/D47858 llvm-svn: 342664
* Temporarily Revert "[New PM] Introducing PassInstrumentation framework"Eric Christopher2018-09-201-1/+0
| | | | | | | | as it was causing failures in the asan buildbot. This reverts commit r342597. llvm-svn: 342616
* [New PM] Introducing PassInstrumentation frameworkFedor Sergeev2018-09-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pass Execution Instrumentation interface enables customizable instrumentation of pass execution, as per "RFC: Pass Execution Instrumentation interface" posted 06/07/2018 on llvm-dev@ The intent is to provide a common machinery to implement all the pass-execution-debugging features like print-before/after, opt-bisect, time-passes etc. Here we get a basic implementation consisting of: * PassInstrumentationCallbacks class that handles registration of callbacks and access to them. * PassInstrumentation class that handles instrumentation-point interfaces that call into PassInstrumentationCallbacks. * Callbacks accept StringRef which is just a name of the Pass right now. There were some ideas to pass an opaque wrapper for the pointer to pass instance, however it appears that pointer does not actually identify the instance (adaptors and managers might have the same address with the pass they govern). Hence it was decided to go simple for now and then later decide on what the proper mental model of identifying a "pass in a phase of pipeline" is. * Callbacks accept llvm::Any serving as a wrapper for const IRUnit*, to remove direct dependencies on different IRUnits (e.g. Analyses). * PassInstrumentationAnalysis analysis is explicitly requested from PassManager through usual AnalysisManager::getResult. All pass managers were updated to run that to get PassInstrumentation object for instrumentation calls. * Using tuples/index_sequence getAnalysisResult helper to extract generic AnalysisManager's extra args out of a generic PassManager's extra args. This is the only way I was able to explicitly run getResult for PassInstrumentationAnalysis out of a generic code like PassManager::run or RepeatedPass::run. TODO: Upon lengthy discussions we agreed to accept this as an initial implementation and then get rid of getAnalysisResult by improving RepeatedPass implementation. * PassBuilder takes PassInstrumentationCallbacks object to pass it further into PassInstrumentationAnalysis. Callbacks registration should be performed directly through PassInstrumentationCallbacks. * new-pm tests updated to account for PassInstrumentationAnalysis being run * Added PassInstrumentation tests to PassBuilderCallbacks unit tests. Other unit tests updated with registration of the now-required PassInstrumentationAnalysis. Reviewers: chandlerc, philip.pfaffe Differential Revision: https://reviews.llvm.org/D47858 llvm-svn: 342597
* Revert rL342544: [New PM] Introducing PassInstrumentation frameworkFedor Sergeev2018-09-191-1/+0
| | | | | | A bunch of bots fail to compile unittests. Reverting. llvm-svn: 342552
* [New PM] Introducing PassInstrumentation frameworkFedor Sergeev2018-09-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Pass Execution Instrumentation interface enables customizable instrumentation of pass execution, as per "RFC: Pass Execution Instrumentation interface" posted 06/07/2018 on llvm-dev@ The intent is to provide a common machinery to implement all the pass-execution-debugging features like print-before/after, opt-bisect, time-passes etc. Here we get a basic implementation consisting of: * PassInstrumentationCallbacks class that handles registration of callbacks and access to them. * PassInstrumentation class that handles instrumentation-point interfaces that call into PassInstrumentationCallbacks. * Callbacks accept StringRef which is just a name of the Pass right now. There were some ideas to pass an opaque wrapper for the pointer to pass instance, however it appears that pointer does not actually identify the instance (adaptors and managers might have the same address with the pass they govern). Hence it was decided to go simple for now and then later decide on what the proper mental model of identifying a "pass in a phase of pipeline" is. * Callbacks accept llvm::Any serving as a wrapper for const IRUnit*, to remove direct dependencies on different IRUnits (e.g. Analyses). * PassInstrumentationAnalysis analysis is explicitly requested from PassManager through usual AnalysisManager::getResult. All pass managers were updated to run that to get PassInstrumentation object for instrumentation calls. * Using tuples/index_sequence getAnalysisResult helper to extract generic AnalysisManager's extra args out of a generic PassManager's extra args. This is the only way I was able to explicitly run getResult for PassInstrumentationAnalysis out of a generic code like PassManager::run or RepeatedPass::run. TODO: Upon lengthy discussions we agreed to accept this as an initial implementation and then get rid of getAnalysisResult by improving RepeatedPass implementation. * PassBuilder takes PassInstrumentationCallbacks object to pass it further into PassInstrumentationAnalysis. Callbacks registration should be performed directly through PassInstrumentationCallbacks. * new-pm tests updated to account for PassInstrumentationAnalysis being run * Added PassInstrumentation tests to PassBuilderCallbacks unit tests. Other unit tests updated with registration of the now-required PassInstrumentationAnalysis. Reviewers: chandlerc, philip.pfaffe Differential Revision: https://reviews.llvm.org/D47858 llvm-svn: 342544
* [IR] Replace `isa<TerminatorInst>` with `isTerminator()`.Chandler Carruth2018-08-261-1/+1
| | | | | | | | | | | | 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
* Remove trailing spaceFangrui Song2018-07-301-3/+3
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338293
* [llvm-opt-fuzzer] Add irce to the fuzzing optionsIgor Laevsky2018-03-201-0/+2
| | | | llvm-svn: 327969
* [llvm-opt-fuzzer] Add another pack of passes for continuous fuzzingIgor Laevsky2018-02-191-5/+25
| | | | | | Differential Revision: https://reviews.llvm.org/D43384 llvm-svn: 325487
* Pass a reference to a module to the bitcode writer.Rafael Espindola2018-02-141-1/+1
| | | | | | | This simplifies most callers as they are already using references or std::unique_ptr. llvm-svn: 325155
* [llvm-opt-fuzzer] Avoid adding incorrect inputs to the fuzzer corpusIgor Laevsky2018-02-051-0/+10
| | | | | | Differential Revision: https://reviews.llvm.org/D42414 llvm-svn: 324225
* [FuzzMutate] Inst deleter doesn't work with PhiNodesIgor Laevsky2018-01-251-4/+9
| | | | | | Differential Revision: https://reviews.llvm.org/D42412 llvm-svn: 323409
* [llvm-opt-fuzzer] Add couple of popular passesIgor Laevsky2018-01-241-0/+8
| | | | | | Differential Revision: https://reviews.llvm.org/D42410 llvm-svn: 323314
* [FuzzMutate] Don't crash when mutator is unable to find operationIgor Laevsky2017-12-191-6/+13
| | | | | | Differential Revision: https://reviews.llvm.org/D41009 llvm-svn: 321062
* Remove redundant includes from various places.Michael Zolotukhin2017-12-131-1/+0
| | | | llvm-svn: 320629
* [FuzzMutate] Only generate loads and stores to the first class sized typesIgor Laevsky2017-12-131-1/+7
| | | | | | Differential Revision: https://reviews.llvm.org/D41109 llvm-svn: 320573
* [FuzzMutate] Correctly split landingpad blocksIgor Laevsky2017-12-131-2/+7
| | | | | | Differential Revision: https://reviews.llvm.org/D41112 llvm-svn: 320571
* [FuzzMutate] Correctly insert sinks and sources around invoke instructionsIgor Laevsky2017-12-081-1/+8
| | | | | | Differential Revision: https://reviews.llvm.org/D40840 llvm-svn: 320136
* [FuzzMutate] Allow only sized pointers for the GEP instructionIgor Laevsky2017-12-071-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D40837 llvm-svn: 320032
* [FuzzMutate] Bailout from injecting into empty basic blocks.Igor Laevsky2017-11-301-0/+2
| | | | | | | | | | In rare cases we can receive request to inject into completelly empty basic block. In the normal case all basic blocks contain at least terminator instruction, but it is possible that the only instruction is catchpad instruction which is not part of the instruction iterator. This case seems rare enough to not care about it. Submiting without review, since it seems almost NFC. I couldn't come up with any reasonable way to test this. llvm-svn: 319444
* [FuzzMutate] Correctly handle vector types in the insertvalue operationIgor Laevsky2017-11-301-4/+6
| | | | | | Differential Revision: https://reviews.llvm.org/D40397 llvm-svn: 319442
* [FuzzMutate] Don't use index operands as sinksIgor Laevsky2017-11-301-2/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D40396 llvm-svn: 319441
* [FuzzMutate] Pick correct index for the insertvalue instructionIgor Laevsky2017-11-301-3/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D40395 llvm-svn: 319440
* [FuzzMutate] Don't create load as a new source if it doesn't match with the ↵Igor Laevsky2017-11-301-11/+14
| | | | | | | | descriptor Differential Revision: https://reviews.llvm.org/D40394 llvm-svn: 319439
* [FuzzMutate] Don't crash when we can't remove instruction from empty functionIgor Laevsky2017-11-301-1/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D40393 llvm-svn: 319438
* [FuzzMutate] Fix windows build after rL318407.Igor Laevsky2017-11-161-1/+1
| | | | | | Add correct library dependence. llvm-svn: 318409
* [FuzzMutate] NFC. Move parseModule and writeModule from llvm-isel-fuzzer ↵Igor Laevsky2017-11-161-0/+36
| | | | | | | | into FuzzMutate. This is to be able to reuse them in the llvm-opt-fuzzer. llvm-svn: 318407
* [llvm-opt-fuzzer] Introduce llvm-opt-fuzzer for fuzzing optimization passesIgor Laevsky2017-11-101-0/+34
| | | | | | | | | This change adds generic fuzzing tools capable of running libFuzzer tests on any optimization pass or combination of them. Differential Revision: https://reviews.llvm.org/D39555 llvm-svn: 317883
* FuzzMutate: Fix arch parsing in FuzzerCLIJustin Bogner2017-10-171-1/+1
| | | | | | | | The right way to parse arch names is by creating a triple. This was using getArchTypeForLLVMName before, which doesn't really do the right thing here. llvm-svn: 315965
* [llvm-isel-fuzzer] Use "--" as separator rather than '='.Matt Morehouse2017-10-131-1/+1
| | | | | | | | | | | | | | Summary: OSS-Fuzz doesn't support '=' in filenames. Reviewers: bogner, kcc Reviewed By: kcc Subscribers: javed.absar, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D38866 llvm-svn: 315647
* Re-commit "llvm-isel-fuzzer: Handle a subset of backend flags in the exec name"Justin Bogner2017-10-121-1/+37
| | | | | | | | | | | | | | | | | | Here we add a secondary option parser to llvm-isel-fuzzer (and provide it for use with other fuzzers). With this, you can copy the fuzzer to a name like llvm-isel-fuzzer=aarch64-gisel for a fuzzer that fuzzer AArch64 with GlobalISel enabled, or fuzzer=x86_64 to fuzz x86, with no flags required. This should be useful for running these in OSS-Fuzz. Note that this handrolls a subset of cl::opts to recognize, rather than embedding a complete command parser for argv[0]. If we find we really need the flexibility of handling arbitrary options at some point we can rethink this. This re-applies 315545 using "=" instead of ":" as a separator for arguments. llvm-svn: 315557
* Revert r315545 "llvm-isel-fuzzer: Handle a subset of backend flags in the ↵Hans Wennborg2017-10-121-37/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | executable name" It broke some tests on Windows: Failing Tests (4): LLVM :: tools/llvm-isel-fuzzer/execname-options.ll LLVM :: tools/llvm-isel-fuzzer/missing-triple.ll LLVM :: tools/llvm-isel-fuzzer/x86-empty-bc.ll LLVM :: tools/llvm-isel-fuzzer/x86-empty.ll > llvm-isel-fuzzer: Handle a subset of backend flags in the executable name > > Here we add a secondary option parser to llvm-isel-fuzzer (and provide > it for use with other fuzzers). With this, you can copy the fuzzer to > a name like llvm-isel-fuzzer:aarch64-gisel for a fuzzer that fuzzer > AArch64 with GlobalISel enabled, or fuzzer:x86_64 to fuzz x86, with no > flags required. This should be useful for running these in OSS-Fuzz. > > Note that this handrolls a subset of cl::opts to recognize, rather > than embedding a complete command parser for argv[0]. If we find we > really need the flexibility of handling arbitrary options at some > point we can rethink this. llvm-svn: 315554
* llvm-isel-fuzzer: Handle a subset of backend flags in the executable nameJustin Bogner2017-10-121-1/+37
| | | | | | | | | | | | | | | Here we add a secondary option parser to llvm-isel-fuzzer (and provide it for use with other fuzzers). With this, you can copy the fuzzer to a name like llvm-isel-fuzzer:aarch64-gisel for a fuzzer that fuzzer AArch64 with GlobalISel enabled, or fuzzer:x86_64 to fuzz x86, with no flags required. This should be useful for running these in OSS-Fuzz. Note that this handrolls a subset of cl::opts to recognize, rather than embedding a complete command parser for argv[0]. If we find we really need the flexibility of handling arbitrary options at some point we can rethink this. llvm-svn: 315545
* Move some CLI utils out of llvm-isel-fuzzer and into the libraryJustin Bogner2017-09-022-0/+64
| | | | | | | | FuzzMutate might not be the best place for these, but it makes more sense than an entirely new library for now. This will make setting up fuzz targets with consistent CLI handling easier. llvm-svn: 312425
* Re-apply "Introduce FuzzMutate library"Justin Bogner2017-08-216-0/+707
| | | | | | | | | | | | | | Same as r311392 with some fixes for library dependencies. Thanks to Chapuni for helping work those out! Original commit message: This introduces the FuzzMutate library, which provides structured fuzzing for LLVM IR, as described in my EuroLLVM 2017 talk. Most of the basic mutators to inject and delete IR are provided, with support for most basic operations. llvm-svn: 311402
* Revert "Re-apply "Introduce FuzzMutate library""Justin Bogner2017-08-216-707/+0
| | | | | | | | | | | The dependencies for the new library seem to be misconfigured on some linux configs: http://bb.pgr.jp/builders/llvm-i686-linux-RA/builds/5435/steps/build_all/logs/stdio This reverts r311392. llvm-svn: 311393
* Re-apply "Introduce FuzzMutate library"Justin Bogner2017-08-216-0/+707
| | | | | | | | | | | | | | | Redo r311356 with a fix to avoid std::uniform_int_distribution<bool>. The bool specialization is undefined according to the standard, even though libc++ seems to have it. Original commit message: This introduces the FuzzMutate library, which provides structured fuzzing for LLVM IR, as described in my [EuroLLVM 2017 talk][1]. Most of the basic mutators to inject and delete IR are provided, with support for most basic operations. llvm-svn: 311392
* Revert "Introduce FuzzMutate library"Justin Bogner2017-08-216-707/+0
| | | | | | | | Looks like this fails to build with libstdc++. This reverts r311356 llvm-svn: 311358
* Introduce FuzzMutate libraryJustin Bogner2017-08-216-0/+707
This introduces the FuzzMutate library, which provides structured fuzzing for LLVM IR, as described in my [EuroLLVM 2017 talk][1]. Most of the basic mutators to inject and delete IR are provided, with support for most basic operations. I will follow up with the instruction selection fuzzer, which is implemented in terms of this library. [1]: http://llvm.org/devmtg/2017-03//2017/02/20/accepted-sessions.html#2 llvm-svn: 311356
OpenPOWER on IntegriCloud