summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/ImplicitNullChecks.cpp
Commit message (Collapse)AuthorAgeFilesLines
* ImplicitNullChecks: Clear kill/dead flags when moving instructions aroundMatthias Braun2017-05-311-2/+14
| | | | | | | The values are marked as livein in the successor blocks so marking them as killed or dead was wrong. llvm-svn: 304366
* CodeGen: Rename DEBUG_TYPE to match passnamesMatthias Braun2017-05-251-2/+2
| | | | | | | | Rename the DEBUG_TYPE to match the names of corresponding passes where it makes sense. Also establish the pattern of simply referencing DEBUG_TYPE instead of repeating the passname where possible. llvm-svn: 303921
* [INC] Test commit. NFC.Serguei Katkov2017-04-121-1/+1
| | | | | | Just an update of comment. llvm-svn: 300026
* [ImplicitNullCheck] Add alias analysis usageSanjoy Das2017-02-281-27/+75
| | | | | | | | | | | | | | | | | | | Summary: With this change ImplicitNullCheck optimization uses alias analysis and can use load/store memory access for implicit null check if there are other load/store before but memory accesses do not alias. Patch by Serguei Katkov! Reviewers: sanjoy Reviewed By: sanjoy Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D30331 llvm-svn: 296440
* [ImplicitNullCheck] Extend Implicit Null Check scope by using storesSanjoy Das2017-02-071-47/+74
| | | | | | | | | | | | | | | | | | | | | Summary: This change allows usage of store instruction for implicit null check. Memory Aliasing Analisys is not used and change conservatively supposes that any store and load may access the same memory. As a result re-ordering of store-store, store-load and load-store is prohibited. Patch by Serguei Katkov! Reviewers: reames, sanjoy Reviewed By: sanjoy Subscribers: atrick, llvm-commits Differential Revision: https://reviews.llvm.org/D29400 llvm-svn: 294338
* [ImplicitNullCheck] Extend canReorder scopeSanjoy Das2017-02-011-3/+4
| | | | | | | | | | | | | | | | | | Summary: This change allows a re-order of two intructions if their uses are overlapped. Patch by Serguei Katkov! Reviewers: reames, sanjoy Reviewed By: sanjoy Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29120 llvm-svn: 293775
* [ImplicitNullCheck] NFC isSuitableMemoryOp cleanupSanjoy Das2017-02-011-13/+23
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: isSuitableMemoryOp method is repsonsible for verification that instruction is a candidate to use in implicit null check. Additionally it checks that base register is not re-defined before. In case base has been re-defined it just returns false and lookup is continued while any suitable instruction will not succeed this check as well. This results in redundant further operations. So when we found that base register has been re-defined we just stop. Patch by Serguei Katkov! Reviewers: reames, sanjoy Reviewed By: sanjoy Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29119 llvm-svn: 293736
* [CodeGen] Rename MachineInstrBuilder::addOperand. NFCDiana Picus2017-01-131-1/+1
| | | | | | | | | | | Rename from addOperand to just add, to match the other method that has been added to MachineInstrBuilder for adding more than just 1 operand. See https://reviews.llvm.org/D28057 for the whole discussion. Differential Revision: https://reviews.llvm.org/D28556 llvm-svn: 291891
* NFC code motion in ImplicitNullChecksSanjoy Das2016-12-231-96/+106
| | | | | | Extract out two large lambdas into top level member functions. llvm-svn: 290395
* Reimplement depedency tracking in the ImplicitNullChecks passSanjoy Das2016-12-231-201/+193
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change rewrites a core component in the ImplicitNullChecks pass for greater simplicity since the original design was over-complicated for no good reason. Please review this as essentially a new pass. The change is almost NFC and I've added a test case for a scenario that this new code handles that wasn't handled earlier. The implicit null check pass, at its core, is a code hoisting transform. It differs from "normal" code transforms in that it speculates potentially faulting instructions (by design), but a lot of the usual hazard detection logic (register read-after-write etc.) still applies. We previously detected hazards by keeping track of registers defined and used by machine instructions over an instruction range, but that was unwieldy and did not actually confer any performance benefits. The intent was to have linear time complexity over the number of machine instructions considered, but it ended up being N^2 is practice. This new version is more obviously O(N^2) (with N capped to 8 by default) in hazard detection. It does not attempt to be clever in tracking register uses or defs (the previous cleverness here was a source of bugs). Once this is checked in, I'll extract out the `IsSuitableMemoryOp` and `CanHoistLoadInst` lambda into member functions (they're too complicated to be inline lambdas) and do some other related NFC cleanups. Reviewers: reames, anna, atrick Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D27592 llvm-svn: 290394
* Delete dead code and add asserts instead; NFCSanjoy Das2016-11-171-7/+3
| | | | llvm-svn: 287214
* [ImplicitNullCheck] Fix an edge case where we were hoisting incorrectlySanjoy Das2016-11-171-1/+19
| | | | | | | | | | | | | | | ImplicitNullCheck keeps track of one instruction that the memory operation depends on that it also hoists with the memory operation. When hoisting this dependency, it would sometimes clobber a live-in value to the basic block we were hoisting the two things out of. Fix this by explicitly looking for such dependencies. I also noticed two redundant checks on `MO.isDef()` in IsMIOperandSafe. They're redundant since register MachineOperands are either Defs or Uses -- there is no third kind. I'll change the checks to asserts in a later commit. llvm-svn: 287213
* [ImplicitNullChecks] Do not not handle call MachineInstrsSanjoy Das2016-11-161-1/+4
| | | | | | | | | | | We don't track callee clobbered registers correctly, so avoid hoisting across calls. Note: for this bug to trigger we need a `readonly` call target, since we already have logic to not hoist across potentially storing instructions either. llvm-svn: 287159
* Finish renaming remaining analyzeBranch functionsMatt Arsenault2016-09-141-1/+1
| | | | llvm-svn: 281535
* Make analyzeBranch family of instruction names consistentMatt Arsenault2016-09-141-1/+1
| | | | | | | analyzeBranch was renamed to use lowercase first, rename the related set to match. llvm-svn: 281506
* MachineFunctionProperties/MIRParser: Rename AllVRegsAllocated->NoVRegs, ↵Matthias Braun2016-08-251-1/+1
| | | | | | | | | | | | | compute it Rename AllVRegsAllocated to NoVRegs. This avoids the connotation of running after register and simply describes that no vregs are used in a machine function. With that we can simply compute the property and do not need to dump/parse it in .mir files. Differential Revision: http://reviews.llvm.org/D23850 llvm-svn: 279698
* Rename AnalyzeBranch* to analyzeBranch*.Jacques Pienaar2016-07-151-1/+1
| | | | | | | | | | | | Summary: NFC. Rename AnalyzeBranch/AnalyzeBranchPredicate to analyzeBranch/analyzeBranchPredicate to follow LLVM coding style and be consistent with TargetInstrInfo's analyzeCompare and analyzeSelect. Reviewers: tstellarAMD, mcrosier Subscribers: mcrosier, jholewinski, jfb, arsenm, dschuff, jyknight, dsanders, nemanjai Differential Revision: https://reviews.llvm.org/D22409 llvm-svn: 275564
* CodeGen: Use MachineInstr& in TargetInstrInfo, NFCDuncan P. N. Exon Smith2016-06-301-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is mostly a mechanical change to make TargetInstrInfo API take MachineInstr& (instead of MachineInstr* or MachineBasicBlock::iterator) when the argument is expected to be a valid MachineInstr. This is a general API improvement. Although it would be possible to do this one function at a time, that would demand a quadratic amount of churn since many of these functions call each other. Instead I've done everything as a block and just updated what was necessary. This is mostly mechanical fixes: adding and removing `*` and `&` operators. The only non-mechanical change is to split ARMBaseInstrInfo::getOperandLatencyImpl out from ARMBaseInstrInfo::getOperandLatency. Previously, the latter took a `MachineInstr*` which it updated to the instruction bundle leader; now, the latter calls the former either with the same `MachineInstr&` or the bundle leader. As a side effect, this removes a bunch of MachineInstr* to MachineBasicBlock::iterator implicit conversions, a necessary step toward fixing PR26753. Note: I updated WebAssembly, Lanai, and AVR (despite being off-by-default) since it turned out to be easy. I couldn't run tests for AVR since llc doesn't link with it turned on. llvm-svn: 274189
* [ImplicitNullChecks] Hoist trivial depdendencies if possibleSanjoy Das2016-06-221-20/+159
| | | | | | | | | | | | | | | | | | | | | | When trying to convert a loading instruction into a FAULTING_LOAD, we sometimes face code like this: if %R10 is not null: %R9<def> = MOV32ri Immediate %R9<def, tied> = AND32rm %R9, 0x20(%R10) else: goto TRAP In these cases we would like to use the AND32rm instruction as the faulting operation by hoisting the "depedency" def-ing %R9 also above the control flow, transforming the program into: %R9<def> = MOV32ri Immediate %R9<def, tied> = FAULTING_LOAD_OP(AND32rm %R9, 0x20(%R10), FailPath: TRAP) This change teaches ImplicitNullChecks to do the above, when safe. llvm-svn: 273501
* [ImplicitNullCchecks] NFC cleanupSanjoy Das2016-06-211-13/+20
| | | | | | | - Remove unsued constructor - Tighten up the interface for NullCheck llvm-svn: 273231
* [ImplicitNullChecks] Account for implicit-defs as well when updating the ↵Quentin Colombet2016-05-031-7/+12
| | | | | | | | | | | | liveness. The replaced load may have implicit-defs and those defs may be used in the block of the original load. Make sure to update the liveness accordingly. This is a generalization of r267817. llvm-svn: 268412
* [X86] Model FAULTING_LOAD_OP as a terminator and branch.Quentin Colombet2016-05-021-13/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | This operation may branch to the handler block and we do not want it to happen anywhere within the basic block. Moreover, by marking it "terminator and branch" the machine verifier does not wrongly assume (because of AnalyzeBranch not knowing better) the branch is analyzable. Indeed, the target was seeing only the unconditional branch and not the faulting load op and thought it was a simple unconditional block. The machine verifier was complaining because of that and moreover, other optimizations could have done wrong transformation! In the process, simplify the representation of the handler block in the faulting load op. Now, we directly reference the handler block instead of using a label. This has the benefits of: 1. MC knows how to issue a label for a BB, so leave that to it. 2. Accessing the target BB from its label is painful, whereas it is direct from a MBB operand. Note: The 2 bytes offset in implicit-null-check.ll comes from the fact the unconditional jumps are not removed anymore, as the whole terminator sequence is not analyzable anymore. Will fix it in a subsequence commit. llvm-svn: 268327
* [ImplicitNullChecks] Properly update the live-in of the block of the memory ↵Quentin Colombet2016-04-271-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | operation. We basically replace: HoistBB: cond_br NullBB, NotNullBB NullBB: ... NotNullBB: <reg> = load into HoistBB <reg> = load_faulting_op NullBB uncond_br NotNullBB NullBB: ... NotNullBB: ## <reg> is now live-in of NotNullBB ... This partially fixes the machine verifier error for test/CodeGen/X86/implicit-null-check.ll, but it still fails because of the implicit CFG structure. llvm-svn: 267817
* Introduce MachineFunctionProperties and the AllVRegsAllocated propertyDerek Schuff2016-03-281-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | MachineFunctionProperties represents a set of properties that a MachineFunction can have at particular points in time. Existing examples of this idea are MachineRegisterInfo::isSSA() and MachineRegisterInfo::tracksLiveness() which will eventually be switched to use this mechanism. This change introduces the AllVRegsAllocated property; i.e. the property that all virtual registers have been allocated and there are no VReg operands left. With this mechanism, passes can declare that they require a particular property to be set, or that they set or clear properties by implementing e.g. MachineFunctionPass::getRequiredProperties(). The MachineFunctionPass base class verifies that the requirements are met, and handles the setting and clearing based on the delcarations. Passes can also directly query and update the current properties of the MF if they want to have conditional behavior. This change annotates the target-independent post-regalloc passes; future changes will also annotate target-specific ones. Reviewers: qcolombet, hfinkel Differential Revision: http://reviews.llvm.org/D18421 llvm-svn: 264593
* [TII] Allow getMemOpBaseRegImmOfs() to accept negative offsets. NFC.Chad Rosier2016-03-091-5/+5
| | | | | | http://reviews.llvm.org/D17967 llvm-svn: 263021
* [ImplicitNulls] Add some clarifying comments; NFCSanjoy Das2015-11-131-1/+25
| | | | llvm-svn: 253020
* [ImplicitNulls] Fix wrapping by breaking up a condition, NFCSanjoy Das2015-11-121-4/+4
| | | | llvm-svn: 252947
* [ImplicitNull] Extract out a HazardDetector class, NFCSanjoy Das2015-11-121-53/+96
| | | | | | This will make later functional changes easier to follow. llvm-svn: 252946
* Introduce enum value for previously defined metadata -- make.implicit Chen Li2015-08-041-1/+2
| | | | | | | | | | | | Summary: This patch adds enum value for an existing metadata type -- make.implicit. Using preassigned enum will be helpful to get compile time type checking and avoid string construction and comparison. The patch also changes uses of make.implicit from string metadata to enum metadata. There is no functionality change. Reviewers: reames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11698 llvm-svn: 243954
* [ImplicitNullChecks] Work with implicit defs.Sanjoy Das2015-07-201-6/+11
| | | | | | | | | | | | | | | Summary: This change generalizes the implicit null checks pass to work with instructions that don't have any explicit register defs. This lets us use X86's `cmp` against memory as faulting load instructions. Reviewers: reames, JosephTremoulet Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11286 llvm-svn: 242703
* [ImplicitNullChecks] Fix a memory leak.Sanjoy Das2015-07-091-1/+1
| | | | llvm-svn: 241851
* [ImplicitNullChecks] Be smarter in picking the memory op.Sanjoy Das2015-07-091-8/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this change ImplicitNullChecks would only pick loads of the form: ``` test Reg, Reg jz elsewhere fallthrough: movl 32(Reg), Reg2 ``` but not (say) ``` test Reg, Reg jz elsewhere fallthrough: inc Reg3 movl 32(Reg), Reg2 ``` This change teaches ImplicitNullChecks to look through "unrelated" instructions like `inc Reg3` when searching for a load instruction to convert to a trapping load. Reviewers: atrick, JosephTremoulet, reames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11044 llvm-svn: 241850
* [FaultMaps] Add statistic to count the # of implicit null checks.Sanjoy Das2015-07-061-0/+8
| | | | llvm-svn: 241521
* [FaultMaps] Let the frontend pre-select implicit null check candidates.Sanjoy Das2015-06-301-0/+7
| | | | | | | | | | | | | | | | | | Summary: This change introduces a !make.implicit metadata that allows the frontend to pre-select the set of explicit null checks that will be considered for transformation into implicit null checks. The reason for not using profiling data instead of !make.implicit is explained in the change to `FaultMaps.rst`. Reviewers: atrick, reames, pgavlin, JosephTremoulet Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10824 llvm-svn: 241116
* Revert r240137 (Fixed/added namespace ending comments using clang-tidy. NFC)Alexander Kornienko2015-06-231-1/+1
| | | | | | Apparently, the style needs to be agreed upon first. llvm-svn: 240390
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-191-1/+1
| | | | | | | | | | | | | The patch is generated using this command: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ llvm/lib/ Thanks to Eugene Kosov for the original patch! llvm-svn: 240137
* Fix "the the" in comments.Eric Christopher2015-06-191-2/+2
| | | | llvm-svn: 240112
* [CodeGen] Add a pass to fold null checks into nearby memory operations.Sanjoy Das2015-06-151-0/+261
Summary: This change adds an "ImplicitNullChecks" target dependent pass. This pass folds null checks into memory operation using the FAULTING_LOAD pseudo-op introduced in previous patches. Depends on D10197 Depends on D10199 Depends on D10200 Reviewers: reames, rnk, pgavlin, JosephTremoulet, atrick Reviewed By: atrick Subscribers: ab, JosephTremoulet, llvm-commits Differential Revision: http://reviews.llvm.org/D10201 llvm-svn: 239743
OpenPOWER on IntegriCloud