summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Utils/Local.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [DebugInfo] LowerDbgDeclare: Add derefs when handling CallInst usersVedant Kumar2018-07-261-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LowerDbgDeclare inserts a dbg.value before each use of an address described by a dbg.declare. When inserting a dbg.value before a CallInst use, however, it fails to append DW_OP_deref to the DIExpression. The DW_OP_deref is needed to reflect the fact that a dbg.value describes a source variable directly (as opposed to a dbg.declare, which relies on pointer indirection). This patch adds in the DW_OP_deref where needed. This results in the correct values being shown during a debug session for a program compiled with ASan and optimizations (see https://reviews.llvm.org/D49520). Note that ConvertDebugDeclareToDebugValue is already correct -- no changes there were needed. One complication is that SelectionDAG is unable to distinguish between direct and indirect frame-index (FRAMEIX) SDDbgValues. This patch also fixes this long-standing issue in order to not regress integration tests relying on the incorrect assumption that all frame-index SDDbgValues are indirect. This is a necessary fix: the newly-added DW_OP_derefs cannot be lowered properly otherwise. Basically the fix prevents a direct SDDbgValue with DIExpression(DW_OP_deref) from being dereferenced twice by a debugger. There were a handful of tests relying on this incorrect "FRAMEIX => indirect" assumption which actually had incorrect DW_AT_locations: these are all fixed up in this patch. Testing: - check-llvm, and an end-to-end test using lldb to debug an optimized program. - Existing unit tests for DIExpression::appendToStack fully cover the new DIExpression::append utility. - check-debuginfo (the debug info integration tests) Differential Revision: https://reviews.llvm.org/D49454 llvm-svn: 338069
* Skip debuginfo intrinsic in markLiveBlocks.Xin Tong2018-07-181-39/+38
| | | | | | | | | | | | | | | | | | | | Summary: The optimizer is 10%+ slower with vs without debuginfo. I started checking where the difference is coming from. I compiled sqlite3.c with and without debug info from CTMark and compare the time difference. I use Xcode Instrument to find where time is spent. This brings about 20ms, out of ~20s. Reviewers: davide, hfinkel Reviewed By: hfinkel Subscribers: hfinkel, aprantl, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D49337 llvm-svn: 337416
* Fix comments which mixed up 'before' and 'after', NFCVedant Kumar2018-07-131-2/+2
| | | | llvm-svn: 337061
* llvm: Add support for "-fno-delete-null-pointer-checks"Manoj Gupta2018-07-091-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Support for this option is needed for building Linux kernel. This is a very frequently requested feature by kernel developers. More details : https://lkml.org/lkml/2018/4/4/601 GCC option description for -fdelete-null-pointer-checks: This Assume that programs cannot safely dereference null pointers, and that no code or data element resides at address zero. -fno-delete-null-pointer-checks is the inverse of this implying that null pointer dereferencing is not undefined. This feature is implemented in LLVM IR in this CL as the function attribute "null-pointer-is-valid"="true" in IR (Under review at D47894). The CL updates several passes that assumed null pointer dereferencing is undefined to not optimize when the "null-pointer-is-valid"="true" attribute is present. Reviewers: t.p.northover, efriedma, jyknight, chandlerc, rnk, srhines, void, george.burgess.iv Reviewed By: efriedma, george.burgess.iv Subscribers: eraman, haicheng, george.burgess.iv, drinkcat, theraven, reames, sanjoy, xbolva00, llvm-commits Differential Revision: https://reviews.llvm.org/D47895 llvm-svn: 336613
* [Local] replaceAllDbgUsesWith: Update debug values before RAUWVedant Kumar2018-07-061-31/+172
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The replaceAllDbgUsesWith utility helps passes preserve debug info when replacing one value with another. This improves upon the existing insertReplacementDbgValues API by: - Updating debug intrinsics in-place, while preventing use-before-def of the replacement value. - Falling back to salvageDebugInfo when a replacement can't be made. - Moving the responsibiliy for rewriting llvm.dbg.* DIExpressions into common utility code. Along with the API change, this teaches replaceAllDbgUsesWith how to create DIExpressions for three basic integer and pointer conversions: - The no-op conversion. Applies when the values have the same width, or have bit-for-bit compatible pointer representations. - Truncation. Applies when the new value is wider than the old one. - Zero/sign extension. Applies when the new value is narrower than the old one. Testing: - check-llvm, check-clang, a stage2 `-g -O3` build of clang, regression/unit testing. - This resolves a number of mis-sized dbg.value diagnostics from Debugify. Differential Revision: https://reviews.llvm.org/D48676 llvm-svn: 336451
* [DebugInfo] Corrections for salvageDebugInfoBjorn Pettersson2018-07-031-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When salvaging a dbg.declare/dbg.addr we should not add DW_OP_stack_value to the DIExpression (see test/Transforms/InstCombine/salvage-dbg-declare.ll). Consider this example %vla = alloca i32, i64 2 call void @llvm.dbg.declare(metadata i32* %vla, metadata !1, metadata !DIExpression()) Instcombine will turn it into %vla1 = alloca [2 x i32] %vla1.sub = getelementptr inbounds [2 x i32], [2 x i32]* %vla, i64 0, i64 0 call void @llvm.dbg.declare(metadata [2 x i32]* %vla1.sub, metadata !19, metadata !DIExpression()) If the GEP can be eliminated, then the dbg.declare will be salvaged and we should get %vla1 = alloca [2 x i32] call void @llvm.dbg.declare(metadata [2 x i32]* %vla1, metadata !19, metadata !DIExpression()) The problem was that salvageDebugInfo did not recognize dbg.declare as being indirect (%vla1 points to the value, it does not hold the value), so we incorrectly got call void @llvm.dbg.declare(metadata [2 x i32]* %vla1, metadata !19, metadata !DIExpression(DW_OP_stack_value)) I also made sure that llvm::salvageDebugInfo and DIExpression::prependOpcodes do not add DW_OP_stack_value to the DIExpression in case no new operands are added to the DIExpression. That way we avoid to, unneccessarily, turn a register location expression into an implicit location expression in some situations (see test11 in test/Transforms/LICM/sinking.ll). Reviewers: aprantl, vsk Reviewed By: aprantl, vsk Subscribers: JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D48837 llvm-svn: 336191
* Use a variable to appease a no-asserts bot, NFCVedant Kumar2018-06-261-0/+1
| | | | | | | Failure URL: http://lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/22836 llvm-svn: 335648
* [Local] Add a convenient insertReplacementDbgValues overload, NFCVedant Kumar2018-06-261-3/+13
| | | | | | | Add an overload for the common case where the replacement dbg.values have the same DIExpressions as the originals. llvm-svn: 335643
* [Local] Sink salvageDI's early exit into helper functions, NFCVedant Kumar2018-06-261-5/+12
| | | | | | | | salvageDebugInfo() performs a check that allows it to exit early without doing a DenseMap lookup. It's a bit neater and marginally more useful to sink this early exit into the findDbg{Addr,Users,Values} helpers. llvm-svn: 335642
* Improve ConvertDebugDeclareToDebugValueBjorn Pettersson2018-06-261-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a follow-up to r334830 and r335031. In the valueCoversEntireFragment check we now also handle the situation when there is a variable length array (VLA) involved, and the length of the array has been reduced to a constant. The ConvertDebugDeclareToDebugValue functions that are related to PHI nodes and load instructions now avoid inserting dbg.value intrinsics when the value does not, for certain, cover the variable/fragment that should be described. In r334830 we assumed that the value always covered the entire var/fragment and we had assertions in the code to show that assumption. However, those asserts failed when compiling code with VLAs, so we removed the asserts in r335031. Now when we know that the valueCoversEntireFragment check can fail also for PHI/Load instructions we avoid to insert the faulty dbg.value intrinsic in such situations. Compared to the Store instruction scenario we simply drop the dbg.value here (as the variable does not change its value due to PHI/Load, so an earlier dbg.value describing the variable should still be valid). Reviewers: aprantl, vsk, efriedma Reviewed By: aprantl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D48547 llvm-svn: 335580
* [Local] Generalize insertReplacementDbgValues, NFCVedant Kumar2018-06-201-5/+5
| | | | | | | | This utility should operate on Values, not Instructions. While I'm here, I've also made it possible to skip emitting replacement dbg.values for certain debug users (by having RewriteExpr return nullptr). llvm-svn: 335152
* [Local] Add a utility to insert replacement dbg.values, NFCVedant Kumar2018-06-201-0/+18
| | | | | | | | | | | | | | | | | | | | | The purpose of this utility is to make it easier for optimizations to insert replacement dbg.values for instructions they are deleting. This is useful in situations where salvageDebugInfo is inapplicable, say, because the new dbg.value cannot refer to an operand of the dying value. The utility is called insertReplacementDbgValues. It assumes that the instruction 'From' is going to be deleted, and inserts replacement dbg.values for each debug user of 'From'. The newly-inserted dbg.values refer to 'To' instead of 'From'. Each replacement dbg.value has the same location and variable as the debug user it replaces, has a DIExpression determined by the result of 'RewriteExpr' applied to an old debug user of 'From', and is placed before 'InsertBefore'. This should simplify future patches, like D48331. llvm-svn: 335144
* Remove valueCoversEntireFragment asserts in ConvertDebugDeclareToDebugValueBjorn Pettersson2018-06-191-6/+0
| | | | | | | | | | | | | | This is a fixup for r334830 causing problems in polly-aosp buildbot. Focus in r334830 was to fix a problem seen with ConvertDebugDeclareToDebugValue involving store instructions. It also added some asserts to find out of similar problems existed for the ConvertDebugDeclareToDebugValue functions involving load and phi instructions. One of those asserts seems to blow in the polly-aosp buildbot, so I'll revert the asserts while debugging. llvm-svn: 335031
* Re-apply "[DebugInfo] Check size of variable in ConvertDebugDeclareToDebugValue"Bjorn Pettersson2018-06-151-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is r334704 (which was reverted in r334732) with a fix for types like x86_fp80. We need to use getTypeAllocSizeInBits and not getTypeStoreSizeInBits to avoid dropping debug info for such types. Original commit msg: > Summary: > Do not convert a DbgDeclare to DbgValue if the store > instruction only refer to a fragment of the variable > described by the DbgDeclare. > > Problem was seen when for example having an alloca for an > array or struct, and there were stores to individual elements. > In the past we inserted a DbgValue intrinsics for each store, > just as if the store wrote the whole variable. > > When handling store instructions we insert a DbgValue that > indicates that the variable is "undefined", as we do not know > which part of the variable that is updated by the store. > > When ConvertDebugDeclareToDebugValue is used with a load/phi > instruction we assert that the referenced value is large enough > to cover the whole variable. Afaict this should be true for all > scenarios where those methods are used on trunk. If the assert > blows in the future I guess we could simply skip to insert a > dbg.value instruction. > > In the future I think we should examine which part of the variable > that is accessed, and add a DbgValue instrinsic with an appropriate > DW_OP_LLVM_fragment expression. > > Reviewers: dblaikie, aprantl, rnk > > Reviewed By: aprantl > > Subscribers: JDevlieghere, llvm-commits > > Tags: #debug-info > > Differential Revision: https://reviews.llvm.org/D48024 llvm-svn: 334830
* Revert rL334704: "[DebugInfo] Check size of variable in ↵Bjorn Pettersson2018-06-141-38/+0
| | | | | | | | | | ConvertDebugDeclareToDebugValue" This reverts commit r334704. Buildbots detected an assertion in "test tsan in debug compiler-rt build". llvm-svn: 334732
* [DebugInfo] Check size of variable in ConvertDebugDeclareToDebugValueBjorn Pettersson2018-06-141-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Do not convert a DbgDeclare to DbgValue if the store instruction only refer to a fragment of the variable described by the DbgDeclare. Problem was seen when for example having an alloca for an array or struct, and there were stores to individual elements. In the past we inserted a DbgValue intrinsics for each store, just as if the store wrote the whole variable. When handling store instructions we insert a DbgValue that indicates that the variable is "undefined", as we do not know which part of the variable that is updated by the store. When ConvertDebugDeclareToDebugValue is used with a load/phi instruction we assert that the referenced value is large enough to cover the whole variable. Afaict this should be true for all scenarios where those methods are used on trunk. If the assert blows in the future I guess we could simply skip to insert a dbg.value instruction. In the future I think we should examine which part of the variable that is accessed, and add a DbgValue instrinsic with an appropriate DW_OP_LLVM_fragment expression. Reviewers: dblaikie, aprantl, rnk Reviewed By: aprantl Subscribers: JDevlieghere, llvm-commits Tags: #debug-info Differential Revision: https://reviews.llvm.org/D48024 llvm-svn: 334704
* Move Analysis/Utils/Local.h back to TransformsDavid Blaikie2018-06-041-1/+1
| | | | | | | | | | Review feedback from r328165. Split out just the one function from the file that's used by Analysis. (As chandlerc pointed out, the original change only moved the header and not the implementation anyway - which was fine for the one function that was used (since it's a template/inlined in the header) but not in general) llvm-svn: 333954
* [LoopInstSimplify] Re-implement the core logic of loop-instsimplify toChandler Carruth2018-05-291-11/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | be both simpler and substantially more efficient. Rather than use a hand-rolled iteration technique that isn't quite the same as RPO, use the pre-built RPO loop body traversal utility. Once visiting the loop body in RPO, we can assert that we visit defs before uses reliably. When this is the case, the only need to iterate is when simplifying a def that is used by a PHI node along a back-edge. With this patch, the first pass over the loop body is just a complete simplification of every instruction across the loop body. When we encounter a use of a simplified instruction that stems from a PHI node in the loop body that has already been visited (due to some cyclic CFG, potentially the loop itself, or a nested loop, or unstructured control flow), we recall that specific PHI node for the second iteration. Nothing else needs to be preserved from iteration to iteration. On the second and later iterations, only instructions known to have simplified inputs are considered, each time starting from a set of PHIs that had simplified inputs along the backedges. Dead instructions are collected along the way, but deleted in a batch at the end of each iteration making the iterations themselves substantially simpler. This uses a new batch API for recursively deleting dead instructions. This alsa changes the routine to visit subloops. Because simplification is fundamentally transitive, we may need to visit the entire loop body, including subloops, to handle knock-on simplification. I've added a basic test file that helps demonstrate that all of these changes work. It includes both straight-forward loops with simplifications as well as interesting PHI-structures, CFG-structures, and a nested loop case. Differential Revision: https://reviews.llvm.org/D47407 llvm-svn: 333461
* Constant fold launder of null and undefPiotr Padlewski2018-05-181-2/+3
| | | | | | | | | | | | | | | Summary: This might be useful because clang will add some barriers for pointer comparisons. Reviewers: majnemer, dberlin, hfinkel, nlewycky, davide, rsmith, amharc, kuhar Subscribers: davide, amharc, llvm-commits Differential Revision: https://reviews.llvm.org/D32423 llvm-svn: 332786
* Rename DEBUG macro to LLVM_DEBUG.Nicola Zaghen2018-05-141-15/+17
| | | | | | | | | | | | | | | | The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM - Manual change to APInt - Manually chage DOCS as regex doesn't match it. In the transition period the DEBUG() macro is still present and aliased to the LLVM_DEBUG() one. Differential Revision: https://reviews.llvm.org/D43624 llvm-svn: 332240
* [STLExtras] Add distance() for ranges, pred_size(), and succ_size()Vedant Kumar2018-05-101-3/+2
| | | | | | | | | | | This commit adds a wrapper for std::distance() which works with ranges. As it would be a common case to write `distance(predecessors(BB))`, this also introduces `pred_size()` and `succ_size()` helpers to make that easier to write. Differential Revision: https://reviews.llvm.org/D46668 llvm-svn: 332057
* [DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.Shiva Chen2018-05-091-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to set breakpoints on labels and list source code around labels, we need collect debug information for labels, i.e., label name, the function label belong, line number in the file, and the address label located. In order to keep these information in LLVM IR and to allow backend to generate debug information correctly. We create a new kind of metadata for labels, DILabel. The format of DILabel is !DILabel(scope: !1, name: "foo", file: !2, line: 3) We hope to keep debug information as much as possible even the code is optimized. So, we create a new kind of intrinsic for label metadata to avoid the metadata is eliminated with basic block. The intrinsic will keep existing if we keep it from optimized out. The format of the intrinsic is llvm.dbg.label(metadata !1) It has only one argument, that is the DILabel metadata. The intrinsic will follow the label immediately. Backend could get the label metadata through the intrinsic's parameter. We also create DIBuilder API for labels to be used by Frontend. Frontend could use createLabel() to allocate DILabel objects, and use insertLabel() to insert llvm.dbg.label intrinsic in LLVM IR. Differential Revision: https://reviews.llvm.org/D45024 Patch by Hsiangkai Wang. llvm-svn: 331841
* Fix a bunch of places where operator-> was used directly on the return from ↵Craig Topper2018-05-051-1/+1
| | | | | | | | | | dyn_cast. Inspired by r331508, I did a grep and found these. Mostly just change from dyn_cast to cast. Some cases also showed a dyn_cast result being converted to bool, so those I changed to isa. llvm-svn: 331577
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-011-4/+4
| | | | | | | | | | | | | | | | We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46290 llvm-svn: 331272
* Fix a bug in GlobalOpt's handling of DIExpressions.Adrian Prantl2018-04-271-2/+2
| | | | | | | | | This patch adds support for fragment expressions TryToShrinkGlobalToBoolean() which were previously just dropped. Thanks to Reid Kleckner for providing me a reproducer! llvm-svn: 331086
* Fix a couple of layering violations in TransformsDavid Blaikie2018-03-211-1/+1
| | | | | | | | | | | | | Remove #include of Transforms/Scalar.h from Transform/Utils to fix layering. Transforms depends on Transforms/Utils, not the other way around. So remove the header and the "createStripGCRelocatesPass" function declaration (& definition) that is unused and motivated this dependency. Move Transforms/Utils/Local.h into Analysis because it's used by Analysis/MemoryBuiltins.cpp. llvm-svn: 328165
* LowerDbgDeclare: ignore dbg.declares for allocas with volatile accessAdrian Prantl2018-03-091-17/+28
| | | | | | | | | | | There is no point in lowering a dbg.declare describing an alloca that has volatile loads or stores as users, since the alloca cannot be elided. Lowering the dbg.declare will result in larger debug info that may also have worse coverage than just describing the alloca. rdar://problem/34496278 llvm-svn: 327092
* [Utils] Salvage debug info in block simplificationVedant Kumar2018-03-021-0/+2
| | | | | | | | | | | | | In stage2 -O3 builds of llc, this results in small but measurable increases in the number of variables with locations, and in the number of unique source variables overall. (According to llvm-dwarfdump --statistics, there are 123 additional variables with locations, which is just a 0.006% improvement). The size of the .debug_loc section of the llc dsym increases by 0.004%. llvm-svn: 326629
* [Utils] Salvage debug info in recursive inst deletionVedant Kumar2018-03-021-0/+1
| | | | | | | | | | In stage2 -O3 builds of llc, this results in a 0.3% increase in the number of variables with locations, and a 0.2% increase in the number of unique source variables overall. The size of the .debug_loc section of the llc dsym increases by 0.5%. llvm-svn: 326621
* [Debug] Add dbg.value intrinsics for PHIs created during LCSSA.Matt Davis2018-02-231-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch is an enhancement to propagate dbg.value information when Phis are created on behalf of LCSSA. I noticed a case where a value carried across a loop was reported as <optimized out>. Specifically this case: ``` int bar(int x, int y) { return x + y; } int foo(int size) { int val = 0; for (int i = 0; i < size; ++i) { val = bar(val, i); // Both val and i are correct } return val; // <optimized out> } ``` In the above case, after all of the interesting computation completes our value is reported as "optimized out." This change will add a dbg.value to correct this. This patch also moves the dbg.value insertion routine from LoopRotation.cpp into Local.cpp, so that we can share it in both places (LoopRotation and LCSSA). Reviewers: mzolotukhin, aprantl, vsk, davide Reviewed By: aprantl, vsk Subscribers: dberlin, llvm-commits Differential Revision: https://reviews.llvm.org/D42551 llvm-svn: 325926
* [Utils] Avoid a hash table lookup in salvageDI, NFCVedant Kumar2018-02-221-0/+5
| | | | | | | | | | | According to the current coverage report salvageDebugInfo() is called 5.12 million times during testing and almost always returns early. The early return depends on LocalAsMetadata::getIfExists returning null, which involves a DenseMap lookup in an LLVMContextImpl. We can probably speed this up by simply checking the IsUsedByMD bit in Value. llvm-svn: 325738
* [Utils] salvageDI: Add a comment and move a call earlier, NFCVedant Kumar2018-02-151-1/+3
| | | | llvm-svn: 325280
* [Utils] Salvage the debug info of DCE'ed 'and' instructionsPetar Jovanovic2018-02-141-0/+3
| | | | | | | | | | Preserve debug info from a dead 'and' instruction with a constant. Patch by Djordje Todorovic. Differential Revision: https://reviews.llvm.org/D43163 llvm-svn: 325119
* Adding a width of the GEP index to the Data Layout.Elena Demikhovsky2018-02-141-2/+2
| | | | | | | | | | | | | | | | | | Making a width of GEP Index, which is used for address calculation, to be one of the pointer properties in the Data Layout. p[address space]:size:memory_size:alignment:pref_alignment:index_size_in_bits. The index size parameter is optional, if not specified, it is equal to the pointer size. Till now, the InstCombiner normalized GEPs and extended the Index operand to the pointer width. It works fine if you can convert pointer to integer for address calculation and all registered targets do this. But some ISAs have very restricted instruction set for the pointer calculation. During discussions were desided to retrieve information for GEP index from the Data Layout. http://lists.llvm.org/pipermail/llvm-dev/2018-January/120416.html I added an interface to the Data Layout and I changed the InstCombiner and some other passes to take the Index width into account. This change does not affect any in-tree target. I added tests to cover data layouts with explicitly specified index size. Differential Revision: https://reviews.llvm.org/D42123 llvm-svn: 325102
* [Utils] Salvage debug info from all no-op castsVedant Kumar2018-02-131-4/+7
| | | | | | | | | | | We already try to salvage debug values from no-op bitcasts and inttoptr instructions: we should handle ptrtoint instructions as well. This saves an additional 24,444 debug values in a stage2 build of clang, and (according to llvm-dwarfdump --statistics) provides an additional 289 unique source variables. llvm-svn: 324982
* [Utils] Salvage debug info of DCE'ed mul/sdiv/srem instructionsVedant Kumar2018-02-131-0/+9
| | | | | | | | | | | | | Here are the number of additional debug values salvaged in a stage2 build of clang: 63 SALVAGE: MUL 1250 SALVAGE: SDIV (No values were salvaged from `srem` instructions in this experiment, but it's a simple case to handle so we might as well.) llvm-svn: 324976
* [Utils] Salvage debug info of DCE'ed shl/lhsr/ashr instructionsVedant Kumar2018-02-131-0/+9
| | | | | | | | | | | Here are the number of additional debug values salvaged in a stage2 build of clang: 1912 SALVAGE: ASHR 405 SALVAGE: LSHR 249 SALVAGE: SHL llvm-svn: 324975
* [Utils] Salvage the debug info of DCE'ed 'sub' instructionsVedant Kumar2018-02-131-0/+3
| | | | | | This salvages 14 debug values in a stage2 build of clang. llvm-svn: 324974
* [Utils] Salvage the debug info of DCE'ed 'xor' instructionsVedant Kumar2018-02-131-11/+21
| | | | | | | | This salvages 259 debug values in a stage2 build of clang. Differential Revision: https://reviews.llvm.org/D43207 llvm-svn: 324973
* [Utils] Salvage debug info from dead 'or' instructionsVedant Kumar2018-02-091-7/+24
| | | | | | | | | | | Extend salvageDebugInfo to preserve the debug info from a dead 'or' with a constant. Patch by Ismail Badawi! Differential Revision: https://reviews.llvm.org/D43129 llvm-svn: 324764
* [Debug] LCSSA: Insert dbg.value at the first available insertion pointVedant Kumar2018-01-251-1/+3
| | | | | | | | | | | Inserting a dbg.value instruction at the start of a basic block with a landingpad instruction triggers a verifier failure. We should be OK if we insert the instruction a bit later. Speculative fix for the bot failure described here: https://reviews.llvm.org/D42551 llvm-svn: 323482
* [Debug] Add a utility to propagate dbg.value to new PHIs, NFCVedant Kumar2018-01-251-0/+38
| | | | | | | | | | This simply moves an existing utility to Utils for reuse. Split out of: https://reviews.llvm.org/D42551 Patch by Matt Davis! llvm-svn: 323471
* [JumpThreading] Preservation of DT and LVI across the passBrian M. Rzycki2018-01-121-46/+163
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: See D37528 for a previous (non-deferred) version of this patch and its description. Preserves dominance in a deferred manner using a new class DeferredDominance. This reduces the performance impact of updating the DominatorTree at every edge insertion and deletion. A user may call DDT->flush() within JumpThreading for an up-to-date DT. This patch currently has one flush() at the end of runImpl() to ensure DT is preserved across the pass. LVI is also preserved to help subsequent passes such as CorrelatedValuePropagation. LVI is simpler to maintain and is done immediately (not deferred). The code to perform the preversation was minimally altered and simply marked as preserved for the PassManager to be informed. This extends the analysis available to JumpThreading for future enhancements such as threading across loop headers. Reviewers: dberlin, kuhar, sebpop Reviewed By: kuhar, sebpop Subscribers: mgorny, dmgreen, kuba, rnk, rsmith, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D40146 llvm-svn: 322401
* [Utils] Simplify salvageDebugInfo, NFCIVedant Kumar2018-01-051-34/+30
| | | | | | | | | Having a single call to findDbgUsers() allows salvageDebugInfo() to return earlier. Differential Revision: https://reviews.llvm.org/D41787 llvm-svn: 321915
* Revert "[JumpThreading] Preservation of DT and LVI across the pass"Reid Kleckner2018-01-041-159/+46
| | | | | | | This reverts r321825, it causes crashes in Chromium. Reproducer forthcoming. llvm-svn: 321832
* [JumpThreading] Preservation of DT and LVI across the passBrian M. Rzycki2018-01-041-46/+159
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: See D37528 for a previous (non-deferred) version of this patch and its description. Preserves dominance in a deferred manner using a new class DeferredDominance. This reduces the performance impact of updating the DominatorTree at every edge insertion and deletion. A user may call DDT->flush() within JumpThreading for an up-to-date DT. This patch currently has one flush() at the end of runImpl() to ensure DT is preserved across the pass. LVI is also preserved to help subsequent passes such as CorrelatedValuePropagation. LVI is simpler to maintain and is done immediately (not deferred). The code to perfom the preversation was minimally altered and was simply marked as preserved for the PassManager to be informed. This extends the analysis available to JumpThreading for future enhancements. One example is loop boundary threading. Reviewers: dberlin, kuhar, sebpop Reviewed By: kuhar, sebpop Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D40146 llvm-svn: 321825
* [Utils/Local] Use `auto` when the type is obvious. NFCI.Davide Italiano2017-12-311-6/+6
| | | | llvm-svn: 321605
* [Utils] Remove commented debug message. NFCI.Davide Italiano2017-12-311-4/+0
| | | | llvm-svn: 321604
* fix typo in comment and remove inaccurate comment; NFCSanjay Patel2017-12-151-2/+0
| | | | llvm-svn: 320838
* Reverting [JumpThreading] Preservation of DT and LVI across the passBrian M. Rzycki2017-12-131-159/+46
| | | | | | | Stage 2 bootstrap failed: http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules-2/builds/14434 llvm-svn: 320641
OpenPOWER on IntegriCloud