summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* Mark <span> as completeMarshall Clow2018-07-251-2/+2
| | | | llvm-svn: 337879
* [x86/SLH] Teach the x86 speculative load hardening pass to hardenChandler Carruth2018-07-252-16/+379
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | against v1.2 BCBS attacks directly. Attacks using spectre v1.2 (a subset of BCBS) are described in the paper here: https://people.csail.mit.edu/vlk/spectre11.pdf The core idea is to speculatively store over the address in a vtable, jumptable, or other target of indirect control flow that will be subsequently loaded. Speculative execution after such a store can forward the stored value to subsequent loads, and if called or jumped to, the speculative execution will be steered to this potentially attacker controlled address. Up until now, this could be mitigated by enableing retpolines. However, that is a relatively expensive technique to mitigate this particular flavor. Especially because in most cases SLH will have already mitigated this. To fully mitigate this with SLH, we need to do two core things: 1) Unfold loads from calls and jumps, allowing the loads to be post-load hardened. 2) Force hardening of incoming registers even if we didn't end up needing to harden the load itself. The reason we need to do these two things is because hardening calls and jumps from this particular variant is importantly different from hardening against leak of secret data. Because the "bad" data here isn't a secret, but in fact speculatively stored by the attacker, it may be loaded from any address, regardless of whether it is read-only memory, mapped memory, or a "hardened" address. The only 100% effective way to harden these instructions is to harden the their operand itself. But to the extent possible, we'd like to take advantage of all the other hardening going on, we just need a fallback in case none of that happened to cover the particular input to the control transfer instruction. For users of SLH, currently they are paing 2% to 6% performance overhead for retpolines, but this mechanism is expected to be substantially cheaper. However, it is worth reminding folks that this does not mitigate all of the things retpolines do -- most notably, variant #2 is not in *any way* mitigated by this technique. So users of SLH may still want to enable retpolines, and the implementation is carefuly designed to gracefully leverage retpolines to avoid the need for further hardening here when they are enabled. Differential Revision: https://reviews.llvm.org/D49663 llvm-svn: 337878
* [CMake] Link static libunwind and libc++abi into libc++ in Fuchsia toolchainPetr Hosek2018-07-251-0/+6
| | | | | | | | | | | When building libc++ for Fuchsia, we want to distribute shared libc++, libc++abi and libunwind as separate libraries, but for static versions we would like to link all of them into libc++ so -lc++ flag has the same effect whether shared or static library is being used. Differential Revision: https://reviews.llvm.org/D49628 llvm-svn: 337877
* [analyzer] Syntactic matcher for leaks associated with run loop and ↵George Karpenkov2018-07-255-0/+330
| | | | | | | | | | | | | | | | | | | | | | | autoreleasepool A checker for detecting leaks resulting from allocating temporary autoreleasing objects before starting the main run loop. Checks for two antipatterns: 1. ObjCMessageExpr followed by [[NARunLoop mainRunLoop] run] in the same autorelease pool. 2. ObjCMessageExpr followed by [[NARunLoop mainRunLoop] run] in no autorelease pool. Happens-before relationship is modeled purely syntactically. rdar://39299145 Differential Revision: https://reviews.llvm.org/D49528 llvm-svn: 337876
* [X86] Use a shift plus an lea for multiplying by a constant that is a power ↵Craig Topper2018-07-254-22/+172
| | | | | | | | of 2 plus 2/4/8. The LEA allows us to combine an add and the multiply by 2/4/8 together so we just need a shift for the larger power of 2. llvm-svn: 337875
* [X86] Expand mul by pow2 + 2 using a shift and two adds similar to what we ↵Craig Topper2018-07-254-11/+162
| | | | | | do for pow2 - 2. llvm-svn: 337874
* Add unit tests for VMRangeRaphael Isemann2018-07-242-0/+153
| | | | | | | | Subscribers: clayborg, labath, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D49415 llvm-svn: 337873
* [sanitizer] Update symbolizer test.Matt Morehouse2018-07-241-0/+4
| | | | llvm-svn: 337872
* [X86] Use a two lea sequence for multiply by 37, 41, and 73.Craig Topper2018-07-245-59/+114
| | | | | | These fit a pattern used by 11, 21, and 19. llvm-svn: 337871
* [X86] Add test cases for multiply by 37, 41, and 73.Craig Topper2018-07-243-0/+330
| | | | | | These can all be handled with 2 LEAs similar to what we do for 11, 19, 21. llvm-svn: 337870
* [X86] Change multiply by 26 to use two multiplies by 5 and an add instead of ↵Craig Topper2018-07-245-37/+41
| | | | | | | | multiply by 3 and 9 and a subtract. Same number of operations, but ending in an add is friendlier due to it being commutable. llvm-svn: 337869
* [CMake] Include CMakeDependentOption in libunwindPetr Hosek2018-07-241-0/+1
| | | | | | | This should resolve the breakage introduced in r337867 which introduced the use of cmake_dependent_option without include the necessary file. llvm-svn: 337868
* [CMake] Option to control whether shared/static library is installedPetr Hosek2018-07-246-19/+49
| | | | | | | | | | | | | Currently it's only possible to control whether shared or static library build of libc++, libc++abi and libunwind is enabled or disabled and whether to install everything we've built or not. However, it'd be useful to have more fine grained control, e.g. when static libraries are merged together into libc++.a we don't need to install libc++abi.a and libunwind.a. This change adds this option. Differential Revision: https://reviews.llvm.org/D49573 llvm-svn: 337867
* Revert "[analyzer] Extend NoStoreFuncVisitor to insert a note on IVars"George Karpenkov2018-07-243-100/+17
| | | | | | | This reverts commit a9e21bd727112cd69eabc1af648c5da6b773d06e. Reverted because the dependency has not landed yet. llvm-svn: 337866
* Add DumpRegisterValue.cpp.Jason Molenda2018-07-241-4/+4
| | | | llvm-svn: 337865
* [analyzer] Extend NoStoreFuncVisitor to insert a note on IVarsGeorge Karpenkov2018-07-243-17/+100
| | | | | | | | | | | | | | The note is added in the following situation: - We are throwing a nullability-related warning on an IVar - The path goes through a method which *could have* (syntactically determined) written into that IVar, but did not rdar://42444460 Differential Revision: https://reviews.llvm.org/D49689 llvm-svn: 337864
* Fix error messages for bad symbols.Rui Ueyama2018-07-242-13/+53
| | | | | | | | | Previously, the error messages didn't contain symbol name because we didn't read a symbol name for these error messages. Differential Revision: https://reviews.llvm.org/D49762 llvm-svn: 337863
* [Sema] Destroy tokens in DeclaratorChunk paramsBenjamin Kramer2018-07-241-2/+1
| | | | | | Otherwise this leaks in some edge cases. llvm-svn: 337862
* [LV] Fix for PR38110, LV encountered llvm_unreachable() Hideki Saito2018-07-242-2/+53
| | | | | | | | | | | | | | Summary: truncateToMinimalBitWidths() doesn't handle all Instructions and the worst case is compiler crash via llvm_unreachable(). Fix is to add a case to handle PHINode and changed the worst case to NO-OP (from compiler crash). Reviewers: sbaranga, mssimpso, hsaito Reviewed By: hsaito Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49461 llvm-svn: 337861
* [clangd] Guard fuzzer against empty inputs.Benjamin Kramer2018-07-241-0/+3
| | | | llvm-svn: 337860
* [SCEV] Add zext(C + x + ...) -> D + zext(C-D + x + ...)<nuw><nsw> transformRoman Tereshin2018-07-243-0/+197
| | | | | | | | | | | | | | | | | | | | | | | | | | if the top level addition in (D + (C-D + x + ...)) could be proven to not wrap, where the choice of D also maximizes the number of trailing zeroes of (C-D + x + ...), ensuring homogeneous behaviour of the transformation and better canonicalization of such expressions. This enables better canonicalization of expressions like 1 + zext(5 + 20 * %x + 24 * %y) and zext(6 + 20 * %x + 24 * %y) which get both transformed to 2 + zext(4 + 20 * %x + 24 * %y) This pattern is common in address arithmetics and the transformation makes it easier for passes like LoadStoreVectorizer to prove that 2 or more memory accesses are consecutive and optimize (vectorize) them. Reviewed By: mzolotukhin Differential Revision: https://reviews.llvm.org/D48853 llvm-svn: 337859
* [X86] When expanding a multiply by a negative of one less than a power of 2, ↵Craig Topper2018-07-242-22/+23
| | | | | | | | | | like 31, don't generate a negate of a subtract that we'll never optimize. We generated a subtract for the power of 2 minus one then negated the result. The negate can be optimized away by swapping the subtract operands, but DAG combine doesn't know how to do that and we don't add any of the new nodes to the worklist anyway. This patch makes use explicitly emit the swapped subtract. llvm-svn: 337858
* Don't lifetime-extend or track lifetime problems through the LHS of '->*'.Richard Smith2018-07-242-1/+7
| | | | | | Fixes a false-positive warning found by selfhost. llvm-svn: 337857
* [X86] Generalize the multiply by 30 lowering to generic multipy by power 2 ↵Craig Topper2018-07-245-59/+216
| | | | | | | | | | minus 2. Use a left shift and 2 subtracts like we do for 30. Move this out from behind the slow lea check since it doesn't even use an LEA. Use this for multiply by 14 as well. llvm-svn: 337856
* Remove unused History classRaphael Isemann2018-07-244-163/+0
| | | | | | | | | | | | | | Summary: This class doesn't seem to be used anywhere, so we might as well remove the code. Reviewers: labath Reviewed By: labath Subscribers: labath, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D49755 llvm-svn: 337855
* [WebAssembly] Add tests for weaker memory consistency orderingsHeejin Ahn2018-07-241-0/+141
| | | | | | | | | | | | | | | | Summary: Currently all wasm atomic memory access instructions are sequentially consistent, so even if LLVM IR specifies weaker orderings than that, we should upgrade them to sequential ordering and treat them in the same way. Reviewers: dschuff Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D49194 llvm-svn: 337854
* [libFuzzer] Handle unstable edges by disregarding unstable edgesMax Moroz2018-07-246-7/+58
| | | | | | | | | | | | | | | | | | | | Summary: Added a new mode within flag -handle_unstable for new unstable handling algorithm that does the following: When an edge is shown as unstable, copy to UnstableCounters the value 0. During ApplyUnstableCounters we copy back the value 0 to ModuleInline8bitCounters if the edge was unstable. This way we would be ignoring completely features that were collected through non-determinism. Unstable hits would be counted as if it never hit. Reviewers: metzman, Dor1s, kcc, morehouse Reviewed By: metzman, morehouse Subscribers: delcypher, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D49684 llvm-svn: 337853
* [X86] Change multiply by 19 to use (9 * X) * 2 + X instead of (5 * X) * 4 - 1.Craig Topper2018-07-245-34/+30
| | | | | | The new lowering can be done in 2 LEAs. The old code took 1 LEA, 1 shift, and 1 sub. llvm-svn: 337851
* Revert "[VFS] Cleanups to VFS interfaces."Jordan Rupprecht2018-07-243-35/+31
| | | | | | This reverts commit r337834 due to test failures. llvm-svn: 337850
* [MachineOutliner][NFC] Move outlined function remark into its own functionJessica Paquette2018-07-241-31/+33
| | | | | | | This pulls the OutlinedFunction remark out into its own function to make the code a bit easier to read. llvm-svn: 337849
* [MachineOutliner][NFC] Move target frame info into OutlinedFunctionJessica Paquette2018-07-247-60/+47
| | | | | | | | | | | | | | Just some gardening here. Similar to how we moved call information into Candidates, this moves outlined frame information into OutlinedFunction. This allows us to remove TargetCostInfo entirely. Anywhere where we returned a TargetCostInfo struct, we now return an OutlinedFunction. This establishes OutlinedFunctions as more of a general repeated sequence, and Candidates as occurrences of those repeated sequences. llvm-svn: 337848
* Put "built-in" function definitions in global Used list, for LTO. (fix bug ↵Peter Collingbourne2018-07-246-5/+17
| | | | | | | | | | | | | | 34169) When building with LTO, builtin functions that are defined but whose calls have not been inserted yet, get internalized. The Global Dead Code Elimination phase in the new LTO implementation then removes these function definitions. Later optimizations add calls to those functions, and the linker then dies complaining that there are no definitions. This CL fixes the new LTO implementation to check if a function is builtin, and if so, to not internalize (and later DCE) the function. As part of this fix I needed to move the RuntimeLibcalls.{def,h} files from the CodeGen subidrectory to the IR subdirectory. I have updated all the files that accessed those two files to access their new location. Fixes PR34169 Patch by Caroline Tice! Differential Revision: https://reviews.llvm.org/D49434 llvm-svn: 337847
* [x86] Teach the x86 backend that it can fold between TCRETURNm* and ↵Chandler Carruth2018-07-242-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TCRETURNr* and fix latent bugs with register class updates. Summary: Enabling this fully exposes a latent bug in the instruction folding: we never update the register constraints for the register operands when fusing a load into another operation. The fused form could, in theory, have different register constraints on its operands. And in fact, TCRETURNm* needs its memory operands to use tailcall compatible registers. I've updated the folding code to re-constrain all the registers after they are mapped onto their new instruction. However, we still can't enable folding in the general case from TCRETURNr* to TCRETURNm* because doing so may require more registers to be available during the tail call. If the call itself uses all but one register, and the folded load would require both a base and index register, there will not be enough registers to allocate the tail call. It would be better, IMO, to teach the register allocator to *unfold* TCRETURNm* when it runs out of registers (or specifically check the number of registers available during the TCRETURNr*) but I'm not going to try and solve that for now. Instead, I've just blocked the forward folding from r -> m, leaving LLVM free to unfold from m -> r as that doesn't introduce new register pressure constraints. The down side is that I don't have anything that will directly exercise this. Instead, I will be immediately using this it my SLH patch. =/ Still worse, without allowing the TCRETURNr* -> TCRETURNm* fold, I don't have any tests that demonstrate the failure to update the memory operand register constraints. This patch still seems correct, but I'm nervous about the degree of testing due to this. Suggestions? Reviewers: craig.topper Subscribers: sanjoy, mcrosier, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D49717 llvm-svn: 337845
* [Inliner] Teach inliner to merge 'min-legal-vector-width' function attributeCraig Topper2018-07-242-0/+28
| | | | | | | | | | | | When we inline a function with a min-legal-vector-width attribute we need to make sure the caller also ends up with at least that vector width. This patch is necessary to make always_inline functions like intrinsics propagate their min-legal-vector-width. Though nothing uses min-legal-vector-width yet. A future patch will add heuristics to preventing inlining with different vector width mismatches. But that code would need to be in inline cost analysis which is separate from the code added here. Differential Revision: https://reviews.llvm.org/D49162 llvm-svn: 337844
* [X86] Add test case to show failure to combine away negates that may be ↵Craig Topper2018-07-241-0/+64
| | | | | | | | | | created by mul by constant expansion. Mul by constant can expand to a sequence that ends with a negate. If the next instruction is an add or sub we might be able to fold the negate away. We currently fail to do this because we explicitly don't add anything to the DAG combine worklist when we expand multiplies. This is primarily to keep the multipy from being reformed, but we should consider adding the users to worklist. llvm-svn: 337843
* [docker] Fix LLVM_EXTERNAL_PROJECTS cmake variable valueAzharuddin Mohammed2018-07-241-2/+2
| | | | | | | | | | | | | | | | | Summary: LLVM_ENABLE_PROJECTS expects a semicolon separated project list. Fixes PR38158. Reviewers: ilya-biryukov Reviewed By: ilya-biryukov Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49712 llvm-svn: 337842
* [MachineOutliner][NFC] Make Candidates own their call informationJessica Paquette2018-07-247-61/+83
| | | | | | | | | | | | | Before this, TCI contained all the call information for each Candidate. This moves that information onto the Candidates. As a result, each Candidate can now supply how it ought to be called. Thus, Candidates will be able to, say, call the same function in cheaper ways when possible. This also removes that information from TCI, since it's no longer used there. A follow-up patch for the AArch64 outliner will demonstrate this. llvm-svn: 337840
* [MachineOutliner][NFC] Move missed opt remark into its own functionJessica Paquette2018-07-241-39/+46
| | | | | | | | Having the missed remark code in the middle of `findCandidates` made the function hard to follow. This yanks that out into a new function, `emitNotOutliningCheaperRemark`. llvm-svn: 337839
* [MachineOutliner][NFC] Sink some candidate logic into OutlinedFunctionJessica Paquette2018-07-242-18/+18
| | | | | | | | | | | | | | | | | Just some simple gardening to improve clarity. Before, we had something along the lines of 1) Create a std::vector of Candidates 2) Create an OutlinedFunction 3) Create a std::vector of pointers to Candidates 4) Copy those over to the OutlinedFunction and the Candidate list Now, OutlinedFunctions create the Candidate pointers. They're still copied over to the main list of Candidates, but it makes it a bit clearer what's going on. llvm-svn: 337838
* [tsan] Fix crash in objc_sync_enter/objc_sync_exit when using an Obj-C ↵Kuba Mracek2018-07-242-2/+88
| | | | | | | | | | tagged pointer Objective-C tagged pointers (either bottom-most or top-most bit is 1) are valid Obj-C objects but are not valid pointers. Make sure we don't crash on them when used in objc_sync_enter/objc_sync_exit. Instead, let's synchronize on a global object. Differential Revision: https://reviews.llvm.org/D49707 llvm-svn: 337837
* Remove stale documentation from InternalsManual.rstErich Keane2018-07-241-5/+0
| | | | | | | The DuplicatesAllowedWhileMerging was removed a while ago, but the documentation remained. llvm-svn: 337835
* [VFS] Cleanups to VFS interfaces.Sam McCall2018-07-243-31/+35
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: - add comments clarifying semantics - Status::copyWithNewName(Status, Name) --> instance method - Status::copyWithNewName(fs::file_status, Name) --> constructor (it's not a copy) - File::getName() -> getRealPath(), reflecting its actual behavior/function and stop returning status().getName() in the base class (callers can do this fallback if they want to, it complicates the contracts). This is mostly NFC, but the behavior of File::getName() affects FileManager's FileEntry::tryGetRealPathName(), which now fails in more cases: - non-real file cases - real-file cases where the underlying vfs::File was opened in a way that doesn't call realpath(). (In these cases we don't know a distinct real name, so in principle it seems OK) Reviewers: klimek Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D49724 llvm-svn: 337834
* [CMake] Fix the setting of LIBCXX_HEADER_DIR in standalone buildPetr Hosek2018-07-242-7/+10
| | | | | | | | | | | | This is an alternative approach to r337727 which broke the build because libc++ headers were copied into the location outside of directories used by Clang. This change sets LIBCXX_HEADER_DIR to different values depending on whether libc++ is being built as part of LLVM w/ per-target multiarch runtime, LLVM or standalone. Differential Revision: https://reviews.llvm.org/D49711 llvm-svn: 337833
* Move dumping code out of RegisterValue classPavel Labath2018-07-2411-77/+128
| | | | | | | | | | | | | | | | | | | | | | | | Summary: The dump function was the only part of this class which depended on high-level functionality. This was due to the DumpDataExtractor function, which uses info from a running target to control dump format (although, RegisterValue doesn't really use the high-level part of DumpDataExtractor). This patch follows the same approach done for the DataExtractor class, and extracts the dumping code into a separate function/file. This file can stay in the higher level code, while the RegisterValue class and anything that does not depend in dumping can stay go to lower layers. The XCode project will need to be updated after this patch. Reviewers: zturner, jingham, clayborg Subscribers: lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D48351 llvm-svn: 337832
* Use SCEV to avoid inserting some bounds checks.Joel Galenson2018-07-242-12/+386
| | | | | | | | This patch uses SCEV to avoid inserting some bounds checks when they are not needed. This slightly improves the performance of code compiled with the bounds check sanitizer. Differential Revision: https://reviews.llvm.org/D49602 llvm-svn: 337830
* [ELF][HEXAGON] Add R_HEX_B15_PCREL_X relocationSid Manning2018-07-242-0/+9
| | | | | | | | Update testcase Differential Revision: https://reviews.llvm.org/D49567 llvm-svn: 337829
* [PredicateInfo] Use custom mangling to support ssa_copy with unnamed types.Florian Hahn2018-07-249-75/+165
| | | | | | | | | | | | | | | | | | This is a workaround and it would be better to fix this generally, but doing it generally is quite tricky. See D48541 and PR38117. Doing it in PredicateInfo directly allows us to use the type address to differentiate different unnamed types, because neither the created declarations nor the ssa_copy calls should be visible after PredicateInfo got destroyed. Reviewers: efriedma, davide Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D49126 llvm-svn: 337828
* [mips] Fix local dynamic TLS with Sym64Simon Atanasyan2018-07-247-26/+25
| | | | | | | | | | | | | | | | For the final DTPREL addition, rather than a lui/daddiu/daddu triple, LLVM was erronously emitting a daddiu/daddiu pair, treating the %dtprel_hi as if it were a %dtprel_lo, since Mips::Hi expands unshifted for Sym64. Instead, use a new TlsHi node and, although unnecessary due to the exact structure of the nodes emitted, use TlsHi for local exec too to prevent future bugs. Also garbage-collect the unused TprelLo and TlsGd nodes, and TprelHi since its functionality is provided by the new common TlsHi node. Patch by James Clarke. Differential revision: https://reviews.llvm.org/D49259 llvm-svn: 337827
* [profile] Fix finding the first and last directory separators on Windows.Igor Kudrin2018-07-241-10/+8
| | | | | | | | | Until now, our code preferred backslashes to slashes, whereas Windows allows using both types of directory separators in one path string. Differential Revision: https://reviews.llvm.org/D49664 llvm-svn: 337826
* [x86/SLH] Extract the core register hardening logic to a low-levelChandler Carruth2018-07-241-36/+73
| | | | | | | | | | | | | | | | | helper and restructure the post-load hardening to use this. This isn't as trivial as I would have liked because the post-load hardening used a trick that only works for it where it swapped in a temporary register to the load rather than replacing anything. However, there is a simple way to do this without that trick that allows this to easily reuse a friendly API for hardening a value in a register. That API will in turn be usable in subsequent patcehs. This also techincally changes the position at which we insert the subreg extraction for the predicate state, but that never resulted in an actual instruction and so tests don't change at all. llvm-svn: 337825
OpenPOWER on IntegriCloud