summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/ImplicitNullChecks.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [NFC] fix trivial typos in comments and documentsHiroshi Inoue2018-01-261-1/+1
| | | | | | "in in" -> "in", "on on" -> "on" etc. llvm-svn: 323508
* [NFC] fix trivial typos in commentsHiroshi Inoue2018-01-171-1/+1
| | | | | | "the the" -> "the" llvm-svn: 322636
* [CodeGen] Use MachineOperand::print in the MIRPrinter for MO_Register.Francis Visoiu Mistrih2017-12-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Work towards the unification of MIR and debug output by refactoring the interfaces. For MachineOperand::print, keep a simple version that can be easily called from `dump()`, and a more complex one which will be called from both the MIRPrinter and MachineInstr::print. Add extra checks inside MachineOperand for detached operands (operands with getParent() == nullptr). https://reviews.llvm.org/D40836 * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" -o -name "*.s" \) -type f -print0 | xargs -0 sed -i '' -E 's/kill: ([^ ]+) ([^ ]+)<def> ([^ ]+)/kill: \1 def \2 \3/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" -o -name "*.s" \) -type f -print0 | xargs -0 sed -i '' -E 's/kill: ([^ ]+) ([^ ]+) ([^ ]+)<def>/kill: \1 \2 def \3/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" -o -name "*.s" \) -type f -print0 | xargs -0 sed -i '' -E 's/kill: def ([^ ]+) ([^ ]+) ([^ ]+)<def>/kill: def \1 \2 def \3/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" -o -name "*.s" \) -type f -print0 | xargs -0 sed -i '' -E 's/<def>//g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" -o -name "*.s" \) -type f -print0 | xargs -0 sed -i '' -E 's/([^ ]+)<kill>/killed \1/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" -o -name "*.s" \) -type f -print0 | xargs -0 sed -i '' -E 's/([^ ]+)<imp-use,kill>/implicit killed \1/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" -o -name "*.s" \) -type f -print0 | xargs -0 sed -i '' -E 's/([^ ]+)<dead>/dead \1/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" -o -name "*.s" \) -type f -print0 | xargs -0 sed -i '' -E 's/([^ ]+)<def[ ]*,[ ]*dead>/dead \1/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" -o -name "*.s" \) -type f -print0 | xargs -0 sed -i '' -E 's/([^ ]+)<imp-def[ ]*,[ ]*dead>/implicit-def dead \1/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" -o -name "*.s" \) -type f -print0 | xargs -0 sed -i '' -E 's/([^ ]+)<imp-def>/implicit-def \1/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" -o -name "*.s" \) -type f -print0 | xargs -0 sed -i '' -E 's/([^ ]+)<imp-use>/implicit \1/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" -o -name "*.s" \) -type f -print0 | xargs -0 sed -i '' -E 's/([^ ]+)<internal>/internal \1/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" -o -name "*.s" \) -type f -print0 | xargs -0 sed -i '' -E 's/([^ ]+)<undef>/undef \1/g' llvm-svn: 320022
* Mark all library options as hidden.Zachary Turner2017-12-011-2/+2
| | | | | | | | | | | | | | | | | These command line options are not intended for public use, and often don't even make sense in the context of a particular tool anyway. About 90% of them are already hidden, but when people add new options they forget to hide them, so if you were to make a brand new tool today, link against one of LLVM's libraries, and run tool -help you would get a bunch of junk that doesn't make sense for the tool you're writing. This patch hides these options. The real solution is to not have libraries defining command line options, but that's a much larger effort and not something I'm prepared to take on. Differential Revision: https://reviews.llvm.org/D40674 llvm-svn: 319505
* [CodeGen] Print register names in lowercase in both MIR and debug outputFrancis Visoiu Mistrih2017-11-281-5/+5
| | | | | | | | | | | As part of the unification of the debug format and the MIR format, always print registers as lowercase. * Only debug printing is affected. It now follows MIR. Differential Revision: https://reviews.llvm.org/D40417 llvm-svn: 319187
* Fix a bunch more layering of CodeGen headers that are in TargetDavid Blaikie2017-11-171-3/+3
| | | | | | | | All these headers already depend on CodeGen headers so moving them into CodeGen fixes the layering (since CodeGen depends on Target, not the other way around). llvm-svn: 318490
* Target/TargetInstrInfo.h -> CodeGen/TargetInstrInfo.h to match layeringDavid Blaikie2017-11-081-1/+1
| | | | | | | | This header includes CodeGen headers, and is not, itself, included by any Target headers, so move it into CodeGen to match the layering of its implementation. llvm-svn: 317647
* Fix implicit null check with negative offsetYichao Yu2017-10-171-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: It seems that negative offset was accidentally allowed in D17967. AFAICT small negative offset should be valid (always raise segfault) on all archs that I'm aware of (especially x86, which is the only one with this optimization enabled) and such case can be useful when loading hiden metadata from an object. However, like the positive side, it should only be done within a certain limit. For now, use the same limit on the positive side for the negative side. A separate option can be added if needs appear. Reviewers: mcrosier, skatkov Reviewed By: skatkov Subscribers: sanjoy, llvm-commits Differential Revision: https://reviews.llvm.org/D38925 llvm-svn: 315991
* [CodeGen] Fix some Clang-tidy modernize-use-using and Include What You Use ↵Eugene Zelenko2017-08-291-13/+27
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 312053
* [ImplicitNullCheck] Fix the bug when dependent instruction accesses memorySerguei Katkov2017-08-091-1/+3
| | | | | | | | | | | | | | It is possible that dependent instruction may access memory. In this case we must reject optimization because the memory change will be visible in null handler basic block. So we will execute an instruction which we must not execute if check fails. Reviewers: sanjoy, reames Reviewed By: sanjoy Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D36392 llvm-svn: 310443
* [ImplicitNullChecks] Uphold an invariant in areMemoryOpsAliasedSerguei Katkov2017-06-211-24/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Right now areMemoryOpsAliased has an assertion justified as: MMO1 should have a value due it comes from operation we'd like to use as implicit null check. assert(MMO1->getValue() && "MMO1 should have a Value!"); However, it is possible for that invariant to not be upheld in the following situation (conceptually): Null check %RAX NotNullSucc: %RAX = LEA %RSP, 16 // I0 %RDX = MOV64rm %RAX // I1 With the current code, we will have an early exit from ImplicitNullChecks::isSuitableMemoryOp on I0 with SR_Unsuitable. However, I1 will look plausible (since it loads from %RAX) and will go ahead and call areMemoryOpsAliased(I1, I0). This will cause us to fail the assert mentioned above since I1 does not load from an IR level value and thus is allowed to have a non-Value base address. The fix is to bail out earlier whenever we see an unsuitable instruction overwrite PointerReg. This would guarantee that when we call areMemoryOpsAliased, we're guaranteed to be looking at an instruction that loads from or stores to an IR level value. Original Patch Author: sanjoy Reviewers: sanjoy, mkazantsev, reames Reviewed By: sanjoy Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D34385 llvm-svn: 305879
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* 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