summaryrefslogtreecommitdiffstats
path: root/llvm/include
Commit message (Collapse)AuthorAgeFilesLines
...
* Use std::reference_wrapper instead of llvm::ReferenceStorageSerge Guelton2018-07-192-14/+2
| | | | | | | Reviewed By: Bigcheese Differential Revision: https://reviews.llvm.org/D49298 llvm-svn: 337444
* [TargetInstPredicate] Add definition of CheckInvalidRegisterOperand.Andrea Di Biagio2018-07-181-0/+3
| | | | | | | This should have been part of r337378. I forgot to svn add it before committing the change. llvm-svn: 337380
* Fix -Wdocumentation warning. NFCI.Simon Pilgrim2018-07-181-1/+1
| | | | llvm-svn: 337368
* CodeGen: Add a target option for emitting .addrsig directives for all ↵Peter Collingbourne2018-07-172-4/+12
| | | | | | | | address-significant symbols. Differential Revision: https://reviews.llvm.org/D48143 llvm-svn: 337331
* MC: Implement support for new .addrsig and .addrsig_sym directives.Peter Collingbourne2018-07-174-0/+17
| | | | | | | | | Part of the address-significance tables proposal: http://lists.llvm.org/pipermail/llvm-dev/2018-May/123514.html Differential Revision: https://reviews.llvm.org/D47744 llvm-svn: 337328
* Add some helper functions to the demangle utility classes.Zachary Turner2018-07-171-6/+8
| | | | | | | | | | | | | | These are all methods that, while not currently used in the Itanium demangler, are generally useful enough that it's likely the itanium demangler could find a use for them. More importantly, they are all necessary for the Microsoft demangler which is up and coming in a subsequent patch. Rather than combine these into a single monolithic patch, I think it makes sense to commit this utility code first since it is very simple, this way it won't detract from the substance of the MS demangler patch. llvm-svn: 337316
* Revert rL337292 due to another MSVC STL problem.Florian Hahn2018-07-171-101/+0
| | | | llvm-svn: 337303
* Recommit r334887: [SmallSet] Add SmallSetIterator.Florian Hahn2018-07-171-0/+101
| | | | | | | Spell out destructor, copy/move constructor and assignment operators for MSVC STL, where set<T>::const_iterator is not trivially copy constructible. llvm-svn: 337292
* [LLVM-C] Add target triple normalization to the C API.whitequark2018-07-171-0/+4
| | | | | | | | | | | | | | | | | | rL333307 was introduced to remove automatic target triple normalization when calling sys::getDefaultTargetTriple(), arguing that users of the latter already called Triple::normalize() if necessary. However, users of the C API currently have no way of doing target triple normalization. This patch introduces an LLVMNormalizeTargetTriple function to the C API which wraps Triple::normalize() and can be used on the result of LLVMGetDefaultTargetTriple to achieve the same effect. Differential Revision: https://reviews.llvm.org/D49414 Reviewed By: whitequark llvm-svn: 337263
* [WebAssembly] Remove ELF file support.Sam Clegg2018-07-164-32/+0
| | | | | | | | | This support was partial and temporary. Now that we have wasm object file support its no longer needed. Differential Revision: https://reviews.llvm.org/D48744 llvm-svn: 337222
* [Intrinsics] define funnel shift IR intrinsics + DAG builder supportSanjay Patel2018-07-161-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | As discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-May/123292.html http://lists.llvm.org/pipermail/llvm-dev/2018-July/124400.html We want to add rotate intrinsics because the IR expansion of that pattern is 4+ instructions, and we can lose pieces of the pattern before it gets to the backend. Generalizing the operation by allowing 2 different input values (plus the 3rd shift/rotate amount) gives us a "funnel shift" operation which may also be a single hardware instruction. Initially, I thought we needed to define new DAG nodes for these ops, and I spent time working on that (much larger patch), but then I concluded that we don't need it. At least as a first step, we have all of the backend support necessary to match these ops...because it was required. And shepherding these through the IR optimizer is the primary concern, so the IR intrinsics are likely all that we'll ever need. There was also a question about converting the intrinsics to the existing ROTL/ROTR DAG nodes (along with improving the oversized shift documentation). Again, I don't think that's strictly necessary (as the test results here prove). That can be an efficiency improvement as a small follow-up patch. So all we're left with is documentation, definition of the IR intrinsics, and DAG builder support. Differential Revision: https://reviews.llvm.org/D49242 llvm-svn: 337221
* [CodeGen] Fix inconsistent declaration parameter nameFangrui Song2018-07-1637-100/+100
| | | | llvm-svn: 337200
* Restore "[ThinLTO] Ensure we always select the same function copy to import"Teresa Johnson2018-07-161-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit r337081, therefore restoring r337050 (and fix in r337059), with test fix for bot failure described after the original description below. In order to always import the same copy of a linkonce function, even when encountering it with different thresholds (a higher one then a lower one), keep track of the summary we decided to import. This ensures that the backend only gets a single definition to import for each GUID, so that it doesn't need to choose one. Move the largest threshold the GUID was considered for import into the current module out of the ImportMap (which is part of a larger map maintained across the whole index), and into a new map just maintained for the current module we are computing imports for. This saves some memory since we no longer have the thresholds maintained across the whole index (and throughout the in-process backends when doing a normal non-distributed ThinLTO build), at the cost of some additional information being maintained for each invocation of ComputeImportForModule (the selected summary pointer for each import). There is an additional map lookup for each callee being considered for importing, however, this was able to subsume a map lookup in the Worklist iteration that invokes computeImportForFunction. We also are able to avoid calling selectCallee if we already failed to import at the same or higher threshold. I compared the run time and peak memory for the SPEC2006 471.omnetpp benchmark (running in-process ThinLTO backends), as well as for a large internal benchmark with a distributed ThinLTO build (so just looking at the thin link time/memory). Across a number of runs with and without this change there was no significant change in the time and memory. (I tried a few other variations of the change but they also didn't improve time or peak memory). The new commit removes a test that no longer makes sense (Transforms/FunctionImport/hotness_based_import2.ll), as exposed by the reverse-iteration bot. The test depends on the order of processing the summary call edges, and actually depended on the old problematic behavior of selecting more than one summary for a given GUID when encountered with different thresholds. There was no guarantee even before that we would eventually pick the linkonce copy with the hottest call edges, it just happened to work with the test and the old code, and there was no guarantee that we would end up importing the selected version of the copy that had the hottest call edges (since the backend would effectively import only one of the selected copies). Reviewers: davidxl Subscribers: mehdi_amini, inglorion, llvm-commits Differential Revision: https://reviews.llvm.org/D48670 llvm-svn: 337184
* [X86][AArch64][DAGCombine] Unfold 'check for [no] signed truncation' patternRoman Lebedev2018-07-161-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=38149 | PR38149 ]] As discussed in https://reviews.llvm.org/D49179#1158957 and later, the IR for 'check for [no] signed truncation' pattern can be improved: https://rise4fun.com/Alive/gBf ^ that pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in signed case, therefore it is probably a good idea to improve it. But the IR-optimal patter does not lower efficiently, so we want to undo it.. This handles the simple pattern. There is a second pattern with predicate and constants inverted. NOTE: we do not check uses here. we always do the transform. Reviewers: spatel, craig.topper, RKSimon, javed.absar Reviewed By: spatel Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D49266 llvm-svn: 337166
* [AccelTable] Provide DWARF5AccelTableStaticData for dsymutil.Jonas Devlieghere2018-07-161-2/+34
| | | | | | | | | | | For dsymutil we want to store offsets in the accelerator table entries rather than DIE pointers. In addition, we need a way to communicate which CU a DIE belongs to. This patch provides support for both of these issues. Differential revision: https://reviews.llvm.org/D49102 llvm-svn: 337158
* [MemorySSAUpdater] Remove deleted trivial Phis from active worksetAlexandros Lamprineas2018-07-161-2/+6
| | | | | | | | | | | | | Bug fix for PR37808. The regression test is a reduced version of the original reproducer attached to the bug report. As stated in the report, the problem was that InsertedPHIs was keeping dangling pointers to deleted Memory-Phis. MemoryPhis are created eagerly and sometimes get zapped shortly afterwards. I've used WeakVH instead of an expensive removal operation from the active workset. Differential Revision: https://reviews.llvm.org/D48372 llvm-svn: 337149
* Recommit r335794 "Add support for generating a call graph profile from ↵Michael J. Spencer2018-07-162-0/+34
| | | | | | Branch Frequency Info." with fix for removed functions. llvm-svn: 337140
* [llvm-mca][BtVer2] teach how to identify false dependencies on partially writtenAndrea Di Biagio2018-07-151-9/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | registers. The goal of this patch is to improve the throughput analysis in llvm-mca for the case where instructions perform partial register writes. On x86, partial register writes are quite difficult to model, mainly because different processors tend to implement different register merging schemes in hardware. When the code contains partial register writes, the IPC (instructions per cycles) estimated by llvm-mca tends to diverge quite significantly from the observed IPC (using perf). Modern AMD processors (at least, from Bulldozer onwards) don't rename partial registers. Quoting Agner Fog's microarchitecture.pdf: " The processor always keeps the different parts of an integer register together. For example, AL and AH are not treated as independent by the out-of-order execution mechanism. An instruction that writes to part of a register will therefore have a false dependence on any previous write to the same register or any part of it." This patch is a first important step towards improving the analysis of partial register updates. It changes the semantic of RegisterFile descriptors in tablegen, and teaches llvm-mca how to identify false dependences in the presence of partial register writes (for more details: see the new code comments in include/Target/TargetSchedule.h - class RegisterFile). This patch doesn't address the case where a write to a part of a register is followed by a read from the whole register. On Intel chips, high8 registers (AH/BH/CH/DH)) can be stored in separate physical registers. However, a later (dirty) read of the full register (example: AX/EAX) triggers a merge uOp, which adds extra latency (and potentially affects the pipe usage). This is a very interesting article on the subject with a very informative answer from Peter Cordes: https://stackoverflow.com/questions/45660139/how-exactly-do-partial-registers-on-haswell-skylake-perform-writing-al-seems-to In future, the definition of RegisterFile can be extended with extra information that may be used to identify delays caused by merge opcodes triggered by a dirty read of a partial write. Differential Revision: https://reviews.llvm.org/D49196 llvm-svn: 337123
* Revert "[ThinLTO] Ensure we always select the same function copy to import"Teresa Johnson2018-07-141-11/+5
| | | | | | | This reverts commits r337050 and r337059. Caused failure in reverse-iteration bot that needs more investigation. llvm-svn: 337081
* Fix comments which mixed up 'before' and 'after', NFCVedant Kumar2018-07-131-1/+1
| | | | llvm-svn: 337061
* Clarify wording of a doxygen comment, NFCVedant Kumar2018-07-131-3/+3
| | | | llvm-svn: 337060
* [ThinLTO] Ensure we always select the same function copy to importTeresa Johnson2018-07-131-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to always import the same copy of a linkonce function, even when encountering it with different thresholds (a higher one then a lower one), keep track of the summary we decided to import. This ensures that the backend only gets a single definition to import for each GUID, so that it doesn't need to choose one. Move the largest threshold the GUID was considered for import into the current module out of the ImportMap (which is part of a larger map maintained across the whole index), and into a new map just maintained for the current module we are computing imports for. This saves some memory since we no longer have the thresholds maintained across the whole index (and throughout the in-process backends when doing a normal non-distributed ThinLTO build), at the cost of some additional information being maintained for each invocation of ComputeImportForModule (the selected summary pointer for each import). There is an additional map lookup for each callee being considered for importing, however, this was able to subsume a map lookup in the Worklist iteration that invokes computeImportForFunction. We also are able to avoid calling selectCallee if we already failed to import at the same or higher threshold. I compared the run time and peak memory for the SPEC2006 471.omnetpp benchmark (running in-process ThinLTO backends), as well as for a large internal benchmark with a distributed ThinLTO build (so just looking at the thin link time/memory). Across a number of runs with and without this change there was no significant change in the time and memory. (I tried a few other variations of the change but they also didn't improve time or peak memory). Reviewers: davidxl Subscribers: mehdi_amini, inglorion, llvm-commits Differential Revision: https://reviews.llvm.org/D48670 llvm-svn: 337050
* [LowerTypeTests] Limit when icall jumptable entries are emittedVlad Tsyrklevich2018-07-131-6/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently LowerTypeTests emits jumptable entries for all live external and address-taken functions; however, we could limit the number of functions that we emit entries for significantly. For Cross-DSO CFI, we continue to emit jumptable entries for all exported definitions. In the non-Cross-DSO CFI case, we only need to emit jumptable entries for live functions that are address-taken in live functions. This ignores exported functions and functions that are only address taken in dead functions. This change uses ThinLTO summary data (now emitted for all modules during ThinLTO builds) to determine address-taken and liveness info. The logic for emitting jumptable entries is more conservative in the regular LTO case because we don't have summary data in the case of monolithic LTO builds; however, once summaries are emitted for all LTO builds we can unify the Thin/monolithic LTO logic to only use summaries to determine the liveness of address taking functions. This change is a partial fix for PR37474. It reduces the build size for nacl_helper by ~2-3%, the reduction is due to nacl_helper compiling in lots of unused code and unused functions that are address taken in dead functions no longer being being considered live due to emitted jumptable references. The reduction for chromium is ~0.1-0.2%. Reviewers: pcc, eugenis, javed.absar Reviewed By: pcc Subscribers: aheejin, dexonsmith, dschuff, mehdi_amini, eraman, steven_wu, llvm-commits, kcc Differential Revision: https://reviews.llvm.org/D47652 llvm-svn: 337038
* [dwarfdump] Add pretty printer for accelerator table based on Atom.Jonas Devlieghere2018-07-131-0/+4
| | | | | | | | For instance, When dumping .apple_types, the second atom represents the DW_TAG. In addition to printing the raw value, we now also pretty print the value if the ATOM tells us how. llvm-svn: 337026
* Revert "CallGraphSCCPass: iterate over all functions."Evgeniy Stepanov2018-07-131-14/+10
| | | | | | | | | | | | This reverts commit r336419: use-after-free on CallGraph::FunctionMap elements due to the use of a stale iterator in CGPassManager::runOnModule. The iterator may be invalidated if a pass removes a function, ex.: llvm::LegacyInlinerBase::inlineCalls inlineCallsImpl llvm::CallGraph::removeFunctionFromModule llvm-svn: 337018
* [cfi-verify] Support AArch64.Joel Galenson2018-07-132-1/+6
| | | | | | | | | | | | This patch adds support for AArch64 to cfi-verify. This required three changes to cfi-verify. First, it generalizes checking if an instruction is a trap by adding a new isTrap flag to TableGen (and defining it for x86 and AArch64). Second, the code that ensures that the operand register is not clobbered between the CFI check and the indirect call needs to allow a single dereference (in x86 this happens as part of the jump instruction). Third, we needed to ensure that return instructions are not counted as indirect branches. Technically, returns are indirect branches and can be covered by CFI, but LLVM's forward-edge CFI does not protect them, and x86 does not consider them, so we keep that behavior. In addition, we had to improve AArch64's code to evaluate the branch target of a MCInst to handle calls where the destination is not the first operand (which it often is not). Differential Revision: https://reviews.llvm.org/D48836 llvm-svn: 337007
* [TableGen] Support multi-alternative pattern fragmentsUlrich Weigand2018-07-131-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A TableGen instruction record usually contains a DAG pattern that will describe the SelectionDAG operation that can be implemented by this instruction. However, there will be cases where several different DAG patterns can all be implemented by the same instruction. The way to represent this today is to write additional patterns in the Pattern (or usually Pat) class that map those extra DAG patterns to the instruction. This usually also works fine. However, I've noticed cases where the current setup seems to require quite a bit of extra (and duplicated) text in the target .td files. For example, in the SystemZ back-end, there are quite a number of instructions that can implement an "add-with-overflow" operation. The same instructions also need to be used to implement just plain addition (simply ignoring the extra overflow output). The current solution requires creating extra Pat pattern for every instruction, duplicating the information about which particular add operands map best to which particular instruction. This patch enhances TableGen to support a new PatFrags class, which can be used to encapsulate multiple alternative patterns that may all match to the same instruction. It operates the same way as the existing PatFrag class, except that it accepts a list of DAG patterns to match instead of just a single one. As an example, we can now define a PatFrags to match either an "add-with-overflow" or a regular add operation: def z_sadd : PatFrags<(ops node:$src1, node:$src2), [(z_saddo node:$src1, node:$src2), (add node:$src1, node:$src2)]>; and then use this in the add instruction pattern: defm AR : BinaryRRAndK<"ar", 0x1A, 0xB9F8, z_sadd, GR32, GR32>; These SystemZ target changes are implemented here as well. Note that PatFrag is now defined as a subclass of PatFrags, which means that some users of internals of PatFrag need to be updated. (E.g. instead of using PatFrag.Fragment you now need to use !head(PatFrag.Fragments).) The implementation is based on the following main ideas: - InlinePatternFragments may now replace each original pattern with several result patterns, not just one. - parseInstructionPattern delays calling InlinePatternFragments and InferAllTypes. Instead, it extracts a single DAG match pattern from the main instruction pattern. - Processing of the DAG match pattern part of the main instruction pattern now shares most code with processing match patterns from the Pattern class. - Direct use of main instruction patterns in InferFromPattern and EmitResultInstructionAsOperand is removed; everything now operates solely on DAG match patterns. Reviewed by: hfinkel Differential Revision: https://reviews.llvm.org/D48545 llvm-svn: 336999
* [SLH] Introduce a new pass to do Speculative Load Hardening to mitigateChandler Carruth2018-07-131-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Spectre variant #1 for x86. There is a lengthy, detailed RFC thread on llvm-dev which discusses the high level issues. High level discussion is probably best there. I've split the design document out of this patch and will land it separately once I update it to reflect the latest edits and updates to the Google doc used in the RFC thread. This patch is really just an initial step. It isn't quite ready for prime time and is only exposed via debugging flags. It has two major limitations currently: 1) It only supports x86-64, and only certain ABIs. Many assumptions are currently hard-coded and need to be factored out of the code here. 2) It doesn't include any options for more fine-grained control, either of which control flow edges are significant or which loads are important to be hardened. 3) The code is still quite rough and the testing lighter than I'd like. However, this is enough for people to begin using. I have had numerous requests from people to be able to experiment with this patch to understand the trade-offs it presents and how to use it. We would also like to encourage work to similar effect in other toolchains. The ARM folks are actively developing a system based on this for AArch64. We hope to merge this with their efforts when both are far enough along. But we also don't want to block making this available on that effort. Many thanks to the *numerous* people who helped along the way here. For this patch in particular, both Eric and Craig did a ton of review to even have confidence in it as an early, rough cut at this functionality. Differential Revision: https://reviews.llvm.org/D44824 llvm-svn: 336990
* [XRay][compiler-rt] Add PID field to llvm-xray tool and add PID metadata ↵Dean Michael Berris2018-07-132-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | record entry in FDR mode Summary: llvm-xray changes: - account-mode - process-id {...} shows after thread-id - convert-mode - process {...} shows after thread - parses FDR and basic mode pid entries - Checks version number for FDR log parsing. Basic logging changes: - Update header version from 2 -> 3 FDR logging changes: - Update header version from 2 -> 3 - in writeBufferPreamble, there is an additional PID Metadata record (after thread id record and tsc record) Test cases changes: - fdr-mode.cc, fdr-single-thread.cc, fdr-thread-order.cc modified to catch process id output in the log. Reviewers: dberris Reviewed By: dberris Subscribers: hiraditya, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D49153 llvm-svn: 336974
* [DomTreeUpdater] Ignore updates when both DT and PDT are nullptrsChijun Sima2018-07-131-20/+23
| | | | | | | | | | | | | | | | | Summary: Previously, when both DT and PDT are nullptrs and the UpdateStrategy is Lazy, DomTreeUpdater still pends updates inside. After this patch, DomTreeUpdater will ignore all updates from(`applyUpdates()/insertEdge*()/deleteEdge*()`) in this case. (call `delBB()` still pends BasicBlock deletion until a flush event according to the doc). The behavior of DomTreeUpdater previously documented won't change after the patch. Reviewers: dmgreen, davide, kuhar, brzycki, grosser Reviewed By: kuhar Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D48974 llvm-svn: 336968
* CodeGen: Remove pipeline dependencies on StackProtector; NFCMatthias Braun2018-07-134-21/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | This re-applies r336929 with a fix to accomodate for the Mips target scheduling multiple SelectionDAG instances into the pass pipeline. PrologEpilogInserter and StackColoring depend on the StackProtector analysis being alive from the point it is run until PEI, which requires that they are all scheduled in the same FunctionPassManager. Inserting a (machine) ModulePass between StackProtector and PEI results in these passes being in separate FunctionPassManagers and the StackProtector is not available for PEI. PEI and StackColoring don't use much information from the StackProtector pass, so transfering the required information to MachineFrameInfo is cleaner than keeping the StackProtector pass around. This commit moves the SSP layout information to MFI instead of keeping it in the pass. This patch set (D37580, D37581, D37582, D37583, D37584, D37585, D37586, D37587) is a first draft of the pagerando implementation described in http://lists.llvm.org/pipermail/llvm-dev/2017-June/113794.html. Patch by Stephen Crane <sjc@immunant.com> Differential Revision: https://reviews.llvm.org/D49256 llvm-svn: 336964
* Revert "(HEAD -> master, origin/master, arcpatch-D37582) CodeGen: Remove ↵Matthias Braun2018-07-124-46/+21
| | | | | | | | | | pipeline dependencies on StackProtector; NFC" This was triggering pass scheduling failures. This reverts commit r336929. llvm-svn: 336934
* CodeGen: Remove pipeline dependencies on StackProtector; NFCMatthias Braun2018-07-124-21/+46
| | | | | | | | | | | | | | | | | | | | | | | PrologEpilogInserter and StackColoring depend on the StackProtector analysis being alive from the point it is run until PEI, which requires that they are all scheduled in the same FunctionPassManager. Inserting a (machine) ModulePass between StackProtector and PEI results in these passes being in separate FunctionPassManagers and the StackProtector is not available for PEI. PEI and StackColoring don't use much information from the StackProtector pass, so transfering the required information to MachineFrameInfo is cleaner than keeping the StackProtector pass around. This commit moves the SSP layout information to MFI instead of keeping it in the pass. This patch set (D37580, D37581, D37582, D37583, D37584, D37585, D37586, D37587) is a first draft of the pagerando implementation described in http://lists.llvm.org/pipermail/llvm-dev/2017-June/113794.html. Patch by Stephen Crane <sjc@immunant.com> Differential Revision: https://reviews.llvm.org/D49256 llvm-svn: 336929
* [DWARF v5] Generate range list tables into the .debug_rnglists section. No ↵Wolfgang Pieb2018-07-121-0/+9
| | | | | | | | | | | | support for split DWARF and no use of DW_FORM_rnglistx with the DW_AT_ranges attribute. Reviewer: aprantl Differential Revision: https://reviews.llvm.org/D49214 llvm-svn: 336927
* Reverted r336805 as it broke llvm-clang-x86_64-expensive-checks-win build botGalina Kistanova2018-07-121-67/+0
| | | | llvm-svn: 336923
* [XRay] Fix machine verifier issues in X86Francis Visoiu Mistrih2018-07-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I'm not sure if this fix is the right thing to do, but it seemed to me that PATCHABLE_RET and PATCHABLE_TAIL_CALL don't have any defs. Running the following: ``` LLVM_ENABLE_MACHINE_VERIFIER=1 ./build/bin/llvm-lit -v -a test/CodeGen/X86/xray-* ``` results in the following tests to fail (along others): ``` LLVM :: CodeGen/X86/xray-attribute-instrumentation.ll LLVM :: CodeGen/X86/xray-custom-log.ll LLVM :: CodeGen/X86/xray-log-args.ll LLVM :: CodeGen/X86/xray-loop-detection.ll LLVM :: CodeGen/X86/xray-multiplerets-in-blocks.mir LLVM :: CodeGen/X86/xray-section-group.ll LLVM :: CodeGen/X86/xray-selective-instrumentation.ll LLVM :: CodeGen/X86/xray-tail-call-sled.ll LLVM :: CodeGen/X86/xray-typed-event-log.ll ``` The errors are: ``` *** Bad machine code: Explicit definition must be a register *** - function: fn - basic block: %bb.0 (0x7fa31a84d908) - instruction: PATCHABLE_RET 2560, $eax - operand 0: 2560 ``` and ``` *** Bad machine code: Explicit definition must be a register *** - function: caller - basic block: %bb.0 (0x7fbff3044108) - instruction: PATCHABLE_TAIL_CALL 3009, @callee, <regmask $bh $bl $bp $bph $bpl $bx $ebp $ebx $hbp $hbx $rbp $rbx $r12 $r13 $r14 $r15 $r12b $r13b $r14b $r15b $r12bh $r13bh $r14bh $r15bh $r12d $r13d $r14d $r15d $r12w $r13w $r14w $r15w $r12wh and 3 more...>, implicit $rsp, implicit $ssp, implicit $rsp, implicit $ssp, implicit $edi - operand 0: 3009 ``` Differential Revision: https://reviews.llvm.org/D49187 llvm-svn: 336906
* Fix -Wdocumentation warnings. NFCI.Simon Pilgrim2018-07-121-4/+4
| | | | llvm-svn: 336895
* [Support] Require llvm::Error passed to formatv() to be wrapped in fmt_consume()Sam McCall2018-07-122-1/+24
| | | | | | | | | | | | | | | | | | Summary: Someone must be responsible for handling an Error. When formatv takes ownership of an Error, the formatv_object destructor must take care of this. Passing an error by value to formatv() is not considered explicit enough to mark the error as handled (see D49013), so we require callers to use a format adapter to confirm this intent. Reviewers: zturner Subscribers: llvm-commits, lhames Differential Revision: https://reviews.llvm.org/D49170 llvm-svn: 336888
* Fix few typos in comments (write access test commit)Stefan Granitz2018-07-122-2/+2
| | | | llvm-svn: 336887
* [Dominators] Add isUpdateLazy() method to the DomTreeUpdaterChijun Sima2018-07-121-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, when people need to deal with DTU with different UpdateStrategy using different actions, they need to ``` if (DTU.getUpdateStrategy() == DomTreeUpdater::UpdateStrategy::Lazy) { ... } if (DTU.getUpdateStrategy() == DomTreeUpdater::UpdateStrategy::Eager) { ... } ``` After the patch, they can avoid code patterns above ``` if (DTU.isUpdateLazy()){ ... } if (!DTU.isUpdateLazy()){ ... } ``` Reviewers: kuhar, brzycki, dmgreen Reviewed By: kuhar Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49056 llvm-svn: 336886
* [InstSimplify] simplify add instruction if two operands are negativeChen Zheng2018-07-121-0/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D49216 llvm-svn: 336881
* [AsmParser] Fix inconsistent declaration parameter nameFangrui Song2018-07-121-4/+4
| | | | llvm-svn: 336879
* [X86] Remove and autoupgrade the scalar fma intrinsics with masking.Craig Topper2018-07-121-51/+0
| | | | | | This converts them to what clang is now using for codegen. Unfortunately, there seem to be a few kinks to work out still. I'll try to address with follow up patches. llvm-svn: 336871
* [MemorySSA] Add APIs to move memory accesses between blocks, following CFG ↵Alina Sbirlea2018-07-112-1/+35
| | | | | | | | | | | | | | | | changes. Summary: The move APIs added in this patch will be used to update MemorySSA when CFG changes merge or split blocks, by moving memory accesses accordingly in MemorySSA's internal data structures. [Split from D45299 for easier review] Reviewers: george.burgess.iv Subscribers: sanjoy, jlebar, Prazek, llvm-commits Differential Revision: https://reviews.llvm.org/D48897 llvm-svn: 336860
* [InstCombine] Fold x & (-1 >> y) == x to x u<= (-1 >> y)Roman Lebedev2018-07-111-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: https://bugs.llvm.org/show_bug.cgi?id=38123 This pattern will be produced by Implicit Integer Truncation sanitizer, https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530 in unsigned case, therefore it is probably a good idea to improve it. https://rise4fun.com/Alive/Rny ^ there are more opportunities for folds, i will follow up with them afterwards. Caveat: this somehow exposes a missing opportunities in `test/Transforms/InstCombine/icmp-logical.ll` It seems, the problem is in `foldLogOpOfMaskedICmps()` in `InstCombineAndOrXor.cpp`. But i'm not quite sure what is wrong, because it calls `getMaskedTypeForICmpPair()`, which calls `decomposeBitTestICmp()` which should already work for these cases... As @spatel notes in https://reviews.llvm.org/D49179#1158760, that code is a rather complex mess, so we'll let it slide. Reviewers: spatel, craig.topper Reviewed By: spatel Subscribers: yamauchi, majnemer, t.p.northover, llvm-commits Differential Revision: https://reviews.llvm.org/D49179 llvm-svn: 336834
* [DebugInfo] Make children iterator bidirectionalJonas Devlieghere2018-07-112-12/+24
| | | | | | | | | Make the DIE iterator bidirectional so we can move to the previous sibling of a DIE. Differential revision: https://reviews.llvm.org/D49173 llvm-svn: 336823
* Recommit r334887: [SmallSet] Add SmallSetIterator.Florian Hahn2018-07-111-0/+67
| | | | | | | This version now uses the subset of is_trivially_XXX provided by GCC 4.8 and llvm/Support/type_traits.h llvm-svn: 336805
* Use debug-prefix-map for AT_NAMEJonas Devlieghere2018-07-112-7/+2
| | | | | | | | | | | | | | | | | | AT_NAME was being emitted before the directory paths were remapped. This ensures that all paths are remapped before anything is emitted. An additional test case has been added. Note that this only works if the replacement string is an absolute path. If not, then AT_decl_file believes the new path is a relative path, and joins that path with the compilation directory. I do not know of a good way to resolve this. Patch by: Siddhartha Bagaria (starsid) Differential revision: https://reviews.llvm.org/D49169 llvm-svn: 336793
* [llvm-readobj] Add -hex-dump (-x) optionPaul Semel2018-07-112-0/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D48281 llvm-svn: 336782
* [TableGen] Add a general-purpose JSON backend.Simon Tatham2018-07-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The aim of this backend is to output everything TableGen knows about the record set, similarly to the default -print-records backend. But where -print-records produces output in TableGen's input syntax (convenient for humans to read), this backend produces it as structured JSON data, which is convenient for loading into standard scripting languages such as Python, in order to extract information from the data set in an automated way. The output data contains a JSON representation of the variable definitions in output 'def' records, and a few pieces of metadata such as which of those definitions are tagged with the 'field' prefix and which defs are derived from which classes. It doesn't dump out absolutely every piece of knowledge it _could_ produce, such as type information and complicated arithmetic operator nodes in abstract superclasses; the main aim is to allow consumers of this JSON dump to essentially act as new backends, and backends don't generally need to depend on that kind of data. The new backend is implemented as an EmitJSON() function similar to all of llvm-tblgen's other EmitFoo functions, except that it lives in lib/TableGen instead of utils/TableGen on the basis that I'm expecting to add it to clang-tblgen too in a future patch. To test it, I've written a Python script that loads the JSON output and tests properties of it based on comments in the .td source - more or less like FileCheck, except that the CHECK: lines have Python expressions after them instead of textual pattern matches. Reviewers: nhaehnle Reviewed By: nhaehnle Subscribers: arichardson, labath, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D46054 llvm-svn: 336771
OpenPOWER on IntegriCloud