summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Instrumentation
Commit message (Collapse)AuthorAgeFilesLines
* MemorySanitizer - silence static analyzer dyn_cast<> null dereference ↵Simon Pilgrim2019-09-261-3/+3
| | | | | | | | warnings. NFCI. The static analyzer is warning about a potential null dereferences, but we should be able to use cast<> directly and if not assert will fire for us. llvm-svn: 372960
* PGOMemOPSizeOpt - silence static analyzer dyn_cast<MemIntrinsic> null ↵Simon Pilgrim2019-09-261-2/+2
| | | | | | | | dereference warning. NFCI. The static analyzer is warning about a potential null dereference, but we should be able to use cast<MemIntrinsic> directly and if not assert will fire for us. llvm-svn: 372959
* [AddressSanitizer] Don't dereference dyn_cast<ConstantInt> results. NFCI.Simon Pilgrim2019-09-201-2/+2
| | | | | | The static analyzer is warning about potential null dereference, but we can use cast<ConstantInt> directly and if not assert will fire for us. llvm-svn: 372429
* [PGO] Change hardcoded thresholds for cold/inlinehint to use summaryTeresa Johnson2019-09-171-18/+21
| | | | | | | | | | | | | | | | | | | | | | | Summary: The PGO counter reading will add cold and inlinehint (hot) attributes to functions that are very cold or hot. This was using hardcoded thresholds, instead of the profile summary cutoffs which are used in other hot/cold detection and are more dynamic and adaptable. Switch to using the summary-based cold/hot detection. The hardcoded limits were causing some code that had a medium level of hotness (per the summary) to be incorrectly marked with a cold attribute, blocking inlining. Reviewers: davidxl Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67673 llvm-svn: 372189
* [PGO] Don't use comdat groups for counters & data on COFFReid Kleckner2019-09-171-12/+17
| | | | | | | | | | | | | | | For COFF, a comdat group is really a symbol marked IMAGE_COMDAT_SELECT_ANY and zero or more other symbols marked IMAGE_COMDAT_SELECT_ASSOCIATIVE. Typically the associative symbols in the group are not external and are not referenced by other TUs, they are things like debug info, C++ dynamic initializers, or other section registration schemes. The Visual C++ linker reports a duplicate symbol error for symbols marked IMAGE_COMDAT_SELECT_ASSOCIATIVE even if they would be discarded after handling the leader symbol. Fixes coverage-inline.cpp in check-profile after r372020. llvm-svn: 372182
* [PGO] Use linkonce_odr linkage for __profd_ variables in comdat groupsReid Kleckner2019-09-161-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes relocations against __profd_ symbols in discarded sections, which is PR41380. In general, instrumentation happens very early, and optimization and inlining happens afterwards. The counters for a function are calculated early, and after inlining, counters for an inlined function may be widely referenced by other functions. For C++ inline functions of all kinds (linkonce_odr & available_externally mainly), instr profiling wants to deduplicate these __profc_ and __profd_ globals. Otherwise the binary would be quite large. I made __profd_ and __profc_ comdat in r355044, but I chose to make __profd_ internal. At the time, I was only dealing with coverage, and in that case, none of the instrumentation needs to reference __profd_. However, if you use PGO, then instrumentation passes add calls to __llvm_profile_instrument_range which reference __profd_ globals. The solution is to make these globals externally visible by using linkonce_odr linkage for data as was done for counters. This is safe because PGO adds a CFG hash to the names of the data and counter globals, so if different TUs have different globals, they will get different data and counter arrays. Reviewers: xur, hans Differential Revision: https://reviews.llvm.org/D67579 llvm-svn: 372020
* Reland "clang-misexpect: Profile Guided Validation of Performance ↵Petr Hosek2019-09-111-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Annotations in LLVM" This patch contains the basic functionality for reporting potentially incorrect usage of __builtin_expect() by comparing the developer's annotation against a collected PGO profile. A more detailed proposal and discussion appears on the CFE-dev mailing list (http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a prototype of the initial frontend changes appear here in D65300 We revised the work in D65300 by moving the misexpect check into the LLVM backend, and adding support for IR and sampling based profiles, in addition to frontend instrumentation. We add new misexpect metadata tags to those instructions directly influenced by the llvm.expect intrinsic (branch, switch, and select) when lowering the intrinsics. The misexpect metadata contains information about the expected target of the intrinsic so that we can check against the correct PGO counter when emitting diagnostics, and the compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight. We use these branch weight values to determine when to emit the diagnostic to the user. A future patch should address the comment at the top of LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and UnlikelyBranchWeight values into a shared space that can be accessed outside of the LowerExpectIntrinsic pass. Once that is done, the misexpect metadata can be updated to be smaller. In the long term, it is possible to reconstruct portions of the misexpect metadata from the existing profile data. However, we have avoided this to keep the code simple, and because some kind of metadata tag will be required to identify which branch/switch/select instructions are influenced by the use of llvm.expect Patch By: paulkirth Differential Revision: https://reviews.llvm.org/D66324 llvm-svn: 371635
* Revert "clang-misexpect: Profile Guided Validation of Performance ↵Dmitri Gribenko2019-09-111-4/+0
| | | | | | | | | | | | | | | | | | | Annotations in LLVM" This reverts commit r371584. It introduced a dependency from compiler-rt to llvm/include/ADT, which is problematic for multiple reasons. One is that it is a novel dependency edge, which needs cross-compliation machinery for llvm/include/ADT (yes, it is true that right now compiler-rt included only header-only libraries, however, if we allow compiler-rt to depend on anything from ADT, other libraries will eventually get used). Secondly, depending on ADT from compiler-rt exposes ADT symbols from compiler-rt, which would cause ODR violations when Clang is built with the profile library. llvm-svn: 371598
* clang-misexpect: Profile Guided Validation of Performance Annotations in LLVMPetr Hosek2019-09-111-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch contains the basic functionality for reporting potentially incorrect usage of __builtin_expect() by comparing the developer's annotation against a collected PGO profile. A more detailed proposal and discussion appears on the CFE-dev mailing list (http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a prototype of the initial frontend changes appear here in D65300 We revised the work in D65300 by moving the misexpect check into the LLVM backend, and adding support for IR and sampling based profiles, in addition to frontend instrumentation. We add new misexpect metadata tags to those instructions directly influenced by the llvm.expect intrinsic (branch, switch, and select) when lowering the intrinsics. The misexpect metadata contains information about the expected target of the intrinsic so that we can check against the correct PGO counter when emitting diagnostics, and the compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight. We use these branch weight values to determine when to emit the diagnostic to the user. A future patch should address the comment at the top of LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and UnlikelyBranchWeight values into a shared space that can be accessed outside of the LowerExpectIntrinsic pass. Once that is done, the misexpect metadata can be updated to be smaller. In the long term, it is possible to reconstruct portions of the misexpect metadata from the existing profile data. However, we have avoided this to keep the code simple, and because some kind of metadata tag will be required to identify which branch/switch/select instructions are influenced by the use of llvm.expect Patch By: paulkirth Differential Revision: https://reviews.llvm.org/D66324 llvm-svn: 371584
* Revert "clang-misexpect: Profile Guided Validation of Performance ↵Petr Hosek2019-09-101-4/+0
| | | | | | | | Annotations in LLVM" This reverts commit r371484: this broke sanitizer-x86_64-linux-fast bot. llvm-svn: 371488
* clang-misexpect: Profile Guided Validation of Performance Annotations in LLVMPetr Hosek2019-09-101-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch contains the basic functionality for reporting potentially incorrect usage of __builtin_expect() by comparing the developer's annotation against a collected PGO profile. A more detailed proposal and discussion appears on the CFE-dev mailing list (http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a prototype of the initial frontend changes appear here in D65300 We revised the work in D65300 by moving the misexpect check into the LLVM backend, and adding support for IR and sampling based profiles, in addition to frontend instrumentation. We add new misexpect metadata tags to those instructions directly influenced by the llvm.expect intrinsic (branch, switch, and select) when lowering the intrinsics. The misexpect metadata contains information about the expected target of the intrinsic so that we can check against the correct PGO counter when emitting diagnostics, and the compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight. We use these branch weight values to determine when to emit the diagnostic to the user. A future patch should address the comment at the top of LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and UnlikelyBranchWeight values into a shared space that can be accessed outside of the LowerExpectIntrinsic pass. Once that is done, the misexpect metadata can be updated to be smaller. In the long term, it is possible to reconstruct portions of the misexpect metadata from the existing profile data. However, we have avoided this to keep the code simple, and because some kind of metadata tag will be required to identify which branch/switch/select instructions are influenced by the use of llvm.expect Patch By: paulkirth Differential Revision: https://reviews.llvm.org/D66324 llvm-svn: 371484
* Change TargetLibraryInfo analysis passes to always require FunctionTeresa Johnson2019-09-076-27/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the first change to enable the TLI to be built per-function so that -fno-builtin* handling can be migrated to use function attributes. See discussion on D61634 for background. This is an enabler for fixing handling of these options for LTO, for example. This change should not affect behavior, as the provided function is not yet used to build a specifically per-function TLI, but rather enables that migration. Most of the changes were very mechanical, e.g. passing a Function to the legacy analysis pass's getTLI interface, or in Module level cases, adding a callback. This is similar to the way the per-function TTI analysis works. There was one place where we were looking for builtins but not in the context of a specific function. See FindCXAAtExit in lib/Transforms/IPO/GlobalOpt.cpp. I'm somewhat concerned my workaround could provide the wrong behavior in some corner cases. Suggestions welcome. Reviewers: chandlerc, hfinkel Subscribers: arsenm, dschuff, jvesely, nhaehnle, mehdi_amini, javed.absar, sbc100, jgravelle-google, eraman, aheejin, steven_wu, george.burgess.iv, dexonsmith, jfb, asbirlea, gchatelet, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66428 llvm-svn: 371284
* [PGO][CHR] Speed up following long, interlinked use-def chains.Hiroshi Yamauchi2019-09-051-5/+14
| | | | | | | | | | | | | | | | | | | Summary: Avoid visiting an instruction more than once by using a map. This is similar to https://reviews.llvm.org/rL361416. Reviewers: davidxl Reviewed By: davidxl Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67198 llvm-svn: 371086
* [NewPM][Sancov] Make Sancov a Module Pass instead of 2 PassesLeonard Chan2019-09-042-228/+130
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch merges the sancov module and funciton passes into one module pass. The reason for this is because we ran into an out of memory error when attempting to run asan fuzzer on some protobufs (pc.cc files). I traced the OOM error to the destructor of SanitizerCoverage where we only call appendTo[Compiler]Used which calls appendToUsedList. I'm not sure where precisely in appendToUsedList causes the OOM, but I am able to confirm that it's calling this function *repeatedly* that causes the OOM. (I hacked sancov a bit such that I can still create and destroy a new sancov on every function run, but only call appendToUsedList after all functions in the module have finished. This passes, but when I make it such that appendToUsedList is called on every sancov destruction, we hit OOM.) I don't think the OOM is from just adding to the SmallSet and SmallVector inside appendToUsedList since in either case for a given module, they'll have the same max size. I suspect that when the existing llvm.compiler.used global is erased, the memory behind it isn't freed. I could be wrong on this though. This patch works around the OOM issue by just calling appendToUsedList at the end of every module run instead of function run. The same amount of constants still get added to llvm.compiler.used, abd we make the pass usage and logic simpler by not having any inter-pass dependencies. Differential Revision: https://reviews.llvm.org/D66988 llvm-svn: 370971
* [Instruction] Add hasMetadata(Kind) helper [NFC]Philip Reames2019-09-042-3/+3
| | | | | | It's a common idiom, so let's add the obvious wrapper for metadata kinds which are basically booleans. llvm-svn: 370933
* [ASan] Make insertion of version mismatch guard configurableJulian Lettner2019-08-281-1/+7
| | | | | | | | | | | | | | | | | | | By default ASan calls a versioned function `__asan_version_mismatch_check_vXXX` from the ASan module constructor to check that the compiler ABI version and runtime ABI version are compatible. This ensures that we get a predictable linker error instead of hard-to-debug runtime errors. Sometimes, however, we want to skip this safety guard. This new command line option allows us to do just that. rdar://47891956 Reviewed By: kubamracek Differential Revision: https://reviews.llvm.org/D66826 llvm-svn: 370258
* [hwasan] Fix test failure in r369721.Evgeniy Stepanov2019-08-261-2/+3
| | | | | | | | | Try harder to emulate "old runtime" in the test. To get the old behavior with the new runtime library, we need both disable personality function wrapping and enable landing pad instrumentation. llvm-svn: 369977
* hwasan: Fix use of uninitialized memory.Peter Collingbourne2019-08-231-11/+12
| | | | | | | Reported by e.g. http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/23071/steps/build%20with%20ninja/logs/stdio llvm-svn: 369815
* hwasan: Untag unwound stack frames by wrapping personality functions.Peter Collingbourne2019-08-231-8/+102
| | | | | | | | | | | | | | | | | | | | | | | One problem with untagging memory in landing pads is that it only works correctly if the function that catches the exception is instrumented. If the function is uninstrumented, we have no opportunity to untag the memory. To address this, replace landing pad instrumentation with personality function wrapping. Each function with an instrumented stack has its personality function replaced with a wrapper provided by the runtime. Functions that did not have a personality function to begin with also get wrappers if they may be unwound past. As the unwinder calls personality functions during stack unwinding, the original personality function is called and the function's stack frame is untagged by the wrapper if the personality function instructs the unwinder to keep unwinding. If unwinding stops at a landing pad, the function is still responsible for untagging its stack frame if it resumes unwinding. The old landing pad mechanism is preserved for compatibility with old runtimes. Differential Revision: https://reviews.llvm.org/D66377 llvm-svn: 369721
* [Sanitizer] Remove unused functionsAlexandre Ganea2019-08-201-9/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D66503 llvm-svn: 369468
* [llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-157-9/+9
| | | | | | | | 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
* hwasan: Instrument globals.Peter Collingbourne2019-08-061-10/+219
| | | | | | | | | | | | | | | | | | Globals are instrumented by adding a pointer tag to their symbol values and emitting metadata into a special section that allows the runtime to tag their memory when the library is loaded. Due to order of initialization issues explained in more detail in the comments, shadow initialization cannot happen during regular global initialization. Instead, the location of the global section is marked using an ELF note, and we require libc support for calling a function provided by the HWASAN runtime when libraries are loaded and unloaded. Based on ideas discussed with @evgeny777 in D56672. Differential Revision: https://reviews.llvm.org/D65770 llvm-svn: 368102
* [WebAssembly] Lower ASan constructor priority on EmscriptenGuanzhong Chen2019-08-061-7/+18
| | | | | | | | | | | | | | | | | | | | | | | Summary: This change gives Emscripten the ability to use more than one constructor priorities that runs before ASan. By convention, constructor priorites 0-100 are reserved for use by the system. ASan on Emscripten now uses priority 50, leaving plenty of room for use by Emscripten before and after ASan. This change is done in response to: https://github.com/emscripten-core/emscripten/pull/9076#discussion_r310323723 Reviewers: kripken, tlively, aheejin Reviewed By: tlively Subscribers: cfe-commits, dschuff, sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits Tags: #llvm, #clang Differential Revision: https://reviews.llvm.org/D65684 llvm-svn: 368101
* Rename F_{None,Text,Append} to OF_{None,Text,Append}. NFCFangrui Song2019-08-052-2/+4
| | | | | | F_{None,Text,Append} are kept for compatibility since r334221. llvm-svn: 367800
* hwasan: Remove unused field CurModuleUniqueId. NFCI.Peter Collingbourne2019-08-021-2/+0
| | | | llvm-svn: 367717
* [IR] Value: add replaceUsesWithIf() utilityRoman Lebedev2019-08-011-5/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: While there is always a `Value::replaceAllUsesWith()`, sometimes the replacement needs to be conditional. I have only cleaned a few cases where `replaceUsesWithIf()` could be used, to both add test coverage, and show that it is actually useful. Reviewers: jdoerfert, spatel, RKSimon, craig.topper Reviewed By: jdoerfert Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, aheejin, george.burgess.iv, asbirlea, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65528 llvm-svn: 367548
* [IR] SelectInst: add swapValues() utilityRoman Lebedev2019-08-011-4/+1
| | | | | | | | | | | | | | | | | | Summary: Sometimes we need to swap true-val and false-val of a `SelectInst`. Having a function for that is nicer than hand-writing it each time. Reviewers: spatel, RKSimon, craig.topper, jdoerfert Reviewed By: jdoerfert Subscribers: jdoerfert, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65520 llvm-svn: 367547
* Reland the "[NewPM] Port Sancov" patch from rL365838. No functionalLeonard Chan2019-07-252-110/+258
| | | | | | | | | | | | | | | | | | | | | changes were made to the patch since then. -------- [NewPM] Port Sancov This patch contains a port of SanitizerCoverage to the new pass manager. This one's a bit hefty. Changes: - Split SanitizerCoverageModule into 2 SanitizerCoverage for passing over functions and ModuleSanitizerCoverage for passing over modules. - ModuleSanitizerCoverage exists for adding 2 module level calls to initialization functions but only if there's a function that was instrumented by sancov. - Added legacy and new PM wrapper classes that own instances of the 2 new classes. - Update llvm tests and add clang tests. llvm-svn: 367053
* Added address-space mangling for stack related intrinsicsChristudasan Devadasan2019-07-222-6/+11
| | | | | | | | | | | | Modified the following 3 intrinsics: int_addressofreturnaddress, int_frameaddress & int_sponentry. Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D64561 llvm-svn: 366679
* [sanitizers] Use covering ObjectFormatType switchesHubert Tong2019-07-191-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch removes the `default` case from some switches on `llvm::Triple::ObjectFormatType`, and cases for the missing enumerators (`UnknownObjectFormat`, `Wasm`, and `XCOFF`) are then added. For `UnknownObjectFormat`, the effect of the action for the `default` case is maintained; otherwise, where `llvm_unreachable` is called, `report_fatal_error` is used instead. Where the `default` case returns a default value, `report_fatal_error` is used for XCOFF as a placeholder. For `Wasm`, the effect of the action for the `default` case in maintained. The code is structured to avoid strongly implying that the `Wasm` case is present for any reason other than to make the switch cover all `ObjectFormatType` enumerator values. Reviewers: sfertile, jasonliu, daltenty Reviewed By: sfertile Subscribers: hiraditya, aheejin, sunfish, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D64222 llvm-svn: 366544
* hwasan: Initialize the pass only once.Peter Collingbourne2019-07-171-6/+19
| | | | | | | | | | This will let us instrument globals during initialization. This required making the new PM pass a module pass, which should still provide access to analyses via the ModuleAnalysisManager. Differential Revision: https://reviews.llvm.org/D64843 llvm-svn: 366379
* Fix parameter name comments using clang-tidy. NFC.Rui Ueyama2019-07-161-1/+1
| | | | | | | | | | | | | | | | | | | | | This patch applies clang-tidy's bugprone-argument-comment tool to LLVM, clang and lld source trees. Here is how I created this patch: $ git clone https://github.com/llvm/llvm-project.git $ cd llvm-project $ mkdir build $ cd build $ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \ -DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \ -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm $ ninja $ parallel clang-tidy -checks='-*,bugprone-argument-comment' \ -config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \ ::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h} llvm-svn: 366177
* hwasan: Pad arrays with non-1 size correctly.Peter Collingbourne2019-07-161-5/+9
| | | | | | | | Spotted by eugenis. Differential Revision: https://reviews.llvm.org/D64783 llvm-svn: 366171
* Revert "[NewPM] Port Sancov"Leonard Chan2019-07-152-244/+117
| | | | | | This reverts commit 5652f35817f07b16f8b3856d594cc42f4d7ee29c. llvm-svn: 366153
* Remove unused methods in Sancov.Leonard Chan2019-07-121-27/+6
| | | | llvm-svn: 365931
* [NewPM] Port SancovLeonard Chan2019-07-112-110/+258
| | | | | | | | | | | | | | | | | This patch contains a port of SanitizerCoverage to the new pass manager. This one's a bit hefty. Changes: - Split SanitizerCoverageModule into 2 SanitizerCoverage for passing over functions and ModuleSanitizerCoverage for passing over modules. - ModuleSanitizerCoverage exists for adding 2 module level calls to initialization functions but only if there's a function that was instrumented by sancov. - Added legacy and new PM wrapper classes that own instances of the 2 new classes. - Update llvm tests and add clang tests. Differential Revision: https://reviews.llvm.org/D62888 llvm-svn: 365838
* hwasan: Improve precision of checks using short granule tags.Peter Collingbourne2019-07-091-14/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A short granule is a granule of size between 1 and `TG-1` bytes. The size of a short granule is stored at the location in shadow memory where the granule's tag is normally stored, while the granule's actual tag is stored in the last byte of the granule. This means that in order to verify that a pointer tag matches a memory tag, HWASAN must check for two possibilities: * the pointer tag is equal to the memory tag in shadow memory, or * the shadow memory tag is actually a short granule size, the value being loaded is in bounds of the granule and the pointer tag is equal to the last byte of the granule. Pointer tags between 1 to `TG-1` are possible and are as likely as any other tag. This means that these tags in memory have two interpretations: the full tag interpretation (where the pointer tag is between 1 and `TG-1` and the last byte of the granule is ordinary data) and the short tag interpretation (where the pointer tag is stored in the granule). When HWASAN detects an error near a memory tag between 1 and `TG-1`, it will show both the memory tag and the last byte of the granule. Currently, it is up to the user to disambiguate the two possibilities. Because this functionality obsoletes the right aligned heap feature of the HWASAN memory allocator (and because we can no longer easily test it), the feature is removed. Also update the documentation to cover both short granule tags and outlined checks. Differential Revision: https://reviews.llvm.org/D63908 llvm-svn: 365551
* [PoisonChecking] Flesh out complete todo list for full coveragePhilip Reames2019-07-091-8/+24
| | | | | Note: I don't actually plan to implement all of the cases at the moment, I'm just documenting them for completeness. There's a couple of cases left which are practically useful for me in debugging loop transforms, and I'll probably stop there for the moment. llvm-svn: 365550
* [PoisonCheker] Support for out of bounds operands on shifts + ↵Philip Reames2019-07-091-1/+41
| | | | | | | | insert/extractelement These are sources of poison which don't come from flags, but are clearly documented in the LangRef. Left off support for scalable vectors for the moment, but should be easy to add if anyone is interested. llvm-svn: 365543
* [PoisonChecking] Add validation rules for "exact" on sdiv/udivPhilip Reames2019-07-091-0/+18
| | | | | | As directly stated in the LangRef, no ambiguity here... llvm-svn: 365538
* Add a transform pass to make the executable semantics of poison explicit in ↵Philip Reames2019-07-092-0/+284
| | | | | | | | | | | | | | | | the IR Implements a transform pass which instruments IR such that poison semantics are made explicit. That is, it provides a (possibly partial) executable semantics for every instruction w.r.t. poison as specified in the LLVM LangRef. There are obvious parallels to the sanitizer tools, but this pass is focused purely on the semantics of LLVM IR, not any particular source language. The target audience for this tool is developers working on or targetting LLVM from a frontend. The idea is to be able to take arbitrary IR (with the assumption of known inputs), and evaluate it concretely after having made poison semantics explicit to detect cases where either a) the original code executes UB, or b) a transform pass introduces UB which didn't exist in the original program. At the moment, this is mostly the framework and still needs to be fleshed out. By reusing existing code we have decent coverage, but there's a lot of cases not yet handled. What's here is good enough to handle interesting cases though; for instance, one of the recent LFTR bugs involved UB being triggered by integer induction variables with nsw/nuw flags would be reported by the current code. (See comment in PoisonChecking.cpp for full explanation and context) Differential Revision: https://reviews.llvm.org/D64215 llvm-svn: 365536
* [IRBuilder] Introduce helpers for and/or of multiple values at oncePhilip Reames2019-07-061-3/+3
| | | | | | | | We had versions of this code scattered around, so consolidate into one location. Not strictly NFC since the order of intermediate results may change in some places, but since these operations are associatives, should not change results. llvm-svn: 365259
* MSan: handle callbr instructionsAlexander Potapenko2019-07-031-21/+21
| | | | | | | | | | | | | | | | | | | | Summary: Handling callbr is very similar to handling an inline assembly call: MSan must checks the instruction's inputs. callbr doesn't (yet) have outputs, so there's nothing to unpoison, and conservative assembly handling doesn't apply either. Fixes PR42479. Reviewers: eugenis Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64072 llvm-svn: 365008
* hwasan: Remove the old frame descriptor mechanism.Peter Collingbourne2019-06-281-81/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D63470 llvm-svn: 364665
* hwasan: Use llvm.read_register intrinsic to read the PC on aarch64 instead ↵Peter Collingbourne2019-06-271-8/+17
| | | | | | | | | | | of taking the function's address. This shaves an instruction (and a GOT entry in PIC code) off prologues of functions with stack variables. Differential Revision: https://reviews.llvm.org/D63472 llvm-svn: 364608
* [WebAssembly] Implement Address Sanitizer for EmscriptenGuanzhong Chen2019-06-261-0/+4
| | | | | | | | | | | | | | | | | | | | | | Summary: This diff enables address sanitizer on Emscripten. On Emscripten, real memory starts at the value passed to --global-base. All memory before this is used as shadow memory, and thus the shadow mapping function is simply dividing by 8. Reviewers: tlively, aheejin, sbc100 Reviewed By: sbc100 Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D63742 llvm-svn: 364468
* [ASan] Use dynamic shadow on 32-bit iOS and simulatorsJulian Lettner2019-06-211-10/+2
| | | | | | | | | | | | | | | | | | | | The VM layout on iOS is not stable between releases. On 64-bit iOS and its derivatives we use a dynamic shadow offset that enables ASan to search for a valid location for the shadow heap on process launch rather than hardcode it. This commit extends that approach for 32-bit iOS plus derivatives and their simulators. rdar://50645192 rdar://51200372 rdar://51767702 Reviewed By: delcypher Differential Revision: https://reviews.llvm.org/D63586 llvm-svn: 364105
* [profile] Solaris ld supports __start___llvm_prof_data etc. labelsRainer Orth2019-06-201-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, many profiling tests on Solaris FAIL like Command Output (stderr): -- Undefined first referenced symbol in file __llvm_profile_register_names_function /tmp/lit_tmp_Nqu4eh/infinite_loop-9dc638.o __llvm_profile_register_function /tmp/lit_tmp_Nqu4eh/infinite_loop-9dc638.o Solaris 11.4 ld supports the non-standard GNU ld extension of adding __start_SECNAME and __stop_SECNAME labels to sections whose names are valid as C identifiers. Given that we already use Solaris 11.4-only features like ld -z gnu-version-script-compat and fully working .preinit_array support in compiler-rt, we don't need to worry about older versions of Solaris ld. The patch documents that support (although the comment in lib/Transforms/Instrumentation/InstrProfiling.cpp (needsRuntimeRegistrationOfSectionRange) is quite cryptic what it's actually about), and adapts the affected testcase not to expect the alternativeq __llvm_profile_register_functions and __llvm_profile_init. It fixes all affected tests. Tested on amd64-pc-solaris2.11. Differential Revision: https://reviews.llvm.org/D41111 llvm-svn: 363984
* [DFSan] Add UnaryOperator visitor to DataFlowSanitizerCameron McInally2019-06-191-0/+5
| | | | | | Differential Revision: https://reviews.llvm.org/D62815 llvm-svn: 363814
* hwasan: Use bits [3..11) of the ring buffer entry address as the base stack tag.Peter Collingbourne2019-06-171-18/+32
| | | | | | | | | | | | | | This saves roughly 32 bytes of instructions per function with stack objects and causes us to preserve enough information that we can recover the original tags of all stack variables. Now that stack tags are deterministic, we no longer need to pass -hwasan-generate-tags-with-calls during check-hwasan. This also means that the new stack tag generation mechanism is exercised by check-hwasan. Differential Revision: https://reviews.llvm.org/D63360 llvm-svn: 363636
OpenPOWER on IntegriCloud