#
074ccf32 |
| 18-Jul-2018 |
Xin Tong <trent.xin.tong@gmail.com> |
Skip debuginfo intrinsic in markLiveBlocks.
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 wi
Skip debuginfo intrinsic in markLiveBlocks.
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
show more ...
|
#
d37e078d |
| 13-Jul-2018 |
Vedant Kumar <vsk@apple.com> |
Fix comments which mixed up 'before' and 'after', NFC
llvm-svn: 337061
|
#
77eeac3d |
| 09-Jul-2018 |
Manoj Gupta <manojgupta@google.com> |
llvm: Add support for "-fno-delete-null-pointer-checks"
Summary: Support for this option is needed for building Linux kernel. This is a very frequently requested feature by kernel developers.
More
llvm: Add support for "-fno-delete-null-pointer-checks"
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
show more ...
|
#
6379a622 |
| 06-Jul-2018 |
Vedant Kumar <vsk@apple.com> |
[Local] replaceAllDbgUsesWith: Update debug values before RAUW
The replaceAllDbgUsesWith utility helps passes preserve debug info when replacing one value with another.
This improves upon the exist
[Local] replaceAllDbgUsesWith: Update debug values before RAUW
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
show more ...
|
#
8dd6cf71 |
| 03-Jul-2018 |
Bjorn Pettersson <bjorn.a.pettersson@ericsson.com> |
[DebugInfo] Corrections for salvageDebugInfo
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-decla
[DebugInfo] Corrections for salvageDebugInfo
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
show more ...
|
#
78ff0f1b |
| 26-Jun-2018 |
Vedant Kumar <vsk@apple.com> |
Use a variable to appease a no-asserts bot, NFC
Failure URL: http://lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/22836
llvm-svn: 335648
|
#
c85ca4cd |
| 26-Jun-2018 |
Vedant Kumar <vsk@apple.com> |
[Local] Add a convenient insertReplacementDbgValues overload, NFC
Add an overload for the common case where the replacement dbg.values have the same DIExpressions as the originals.
llvm-svn: 335643
|
#
de46f65b |
| 26-Jun-2018 |
Vedant Kumar <vsk@apple.com> |
[Local] Sink salvageDI's early exit into helper functions, NFC
salvageDebugInfo() performs a check that allows it to exit early without doing a DenseMap lookup. It's a bit neater and marginally more
[Local] Sink salvageDI's early exit into helper functions, NFC
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
show more ...
|
#
550517bc |
| 26-Jun-2018 |
Bjorn Pettersson <bjorn.a.pettersson@ericsson.com> |
Improve ConvertDebugDeclareToDebugValue
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
Improve ConvertDebugDeclareToDebugValue
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
show more ...
|
#
4e93f3dc |
| 20-Jun-2018 |
Vedant Kumar <vsk@apple.com> |
[Local] Generalize insertReplacementDbgValues, NFC
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 cer
[Local] Generalize insertReplacementDbgValues, NFC
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
show more ...
|
#
6fa24b0b |
| 20-Jun-2018 |
Vedant Kumar <vsk@apple.com> |
[Local] Add a utility to insert replacement dbg.values, NFC
The purpose of this utility is to make it easier for optimizations to insert replacement dbg.values for instructions they are deleting. Th
[Local] Add a utility to insert replacement dbg.values, NFC
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
show more ...
|
#
2015a399 |
| 19-Jun-2018 |
Bjorn Pettersson <bjorn.a.pettersson@ericsson.com> |
Remove valueCoversEntireFragment asserts in ConvertDebugDeclareToDebugValue
This is a fixup for r334830 causing problems in polly-aosp buildbot.
Focus in r334830 was to fix a problem seen with Conv
Remove valueCoversEntireFragment asserts in ConvertDebugDeclareToDebugValue
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
show more ...
|
#
428caf98 |
| 15-Jun-2018 |
Bjorn Pettersson <bjorn.a.pettersson@ericsson.com> |
Re-apply "[DebugInfo] Check size of variable in ConvertDebugDeclareToDebugValue"
This is r334704 (which was reverted in r334732) with a fix for types like x86_fp80. We need to use getTypeAllocSizeIn
Re-apply "[DebugInfo] Check size of variable in ConvertDebugDeclareToDebugValue"
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
show more ...
|
Revision tags: llvmorg-6.0.1, llvmorg-6.0.1-rc3 |
|
#
972fd1c9 |
| 14-Jun-2018 |
Bjorn Pettersson <bjorn.a.pettersson@ericsson.com> |
Revert rL334704: "[DebugInfo] Check size of variable in ConvertDebugDeclareToDebugValue"
This reverts commit r334704.
Buildbots detected an assertion in "test tsan in debug compiler-rt build".
llv
Revert rL334704: "[DebugInfo] Check size of variable in ConvertDebugDeclareToDebugValue"
This reverts commit r334704.
Buildbots detected an assertion in "test tsan in debug compiler-rt build".
llvm-svn: 334732
show more ...
|
#
e406b29c |
| 14-Jun-2018 |
Bjorn Pettersson <bjorn.a.pettersson@ericsson.com> |
[DebugInfo] Check size of variable in ConvertDebugDeclareToDebugValue
Summary: Do not convert a DbgDeclare to DbgValue if the store instruction only refer to a fragment of the variable described by
[DebugInfo] Check size of variable in ConvertDebugDeclareToDebugValue
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
show more ...
|
#
31b98d2e |
| 04-Jun-2018 |
David Blaikie <dblaikie@gmail.com> |
Move Analysis/Utils/Local.h back to Transforms
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 onl
Move Analysis/Utils/Local.h back to Transforms
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
show more ...
|
Revision tags: llvmorg-6.0.1-rc2 |
|
#
4cbcbb07 |
| 29-May-2018 |
Chandler Carruth <chandlerc@gmail.com> |
[LoopInstSimplify] Re-implement the core logic of loop-instsimplify to be both simpler and substantially more efficient.
Rather than use a hand-rolled iteration technique that isn't quite the same a
[LoopInstSimplify] Re-implement the core logic of loop-instsimplify to 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
show more ...
|
#
a26a08cb |
| 18-May-2018 |
Piotr Padlewski <piotr.padlewski@gmail.com> |
Constant fold launder of null and undef
Summary: This might be useful because clang will add some barriers for pointer comparisons.
Reviewers: majnemer, dberlin, hfinkel, nlewycky, davide, rsmith,
Constant fold launder of null and undef
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
show more ...
|
#
d34e60ca |
| 14-May-2018 |
Nicola Zaghen <nicola.zaghen@imgtec.com> |
Rename DEBUG macro to LLVM_DEBUG. 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\?(/
Rename DEBUG macro to LLVM_DEBUG. 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
show more ...
|
#
e0b5f86b |
| 10-May-2018 |
Vedant Kumar <vsk@apple.com> |
[STLExtras] Add distance() for ranges, pred_size(), and succ_size()
This commit adds a wrapper for std::distance() which works with ranges. As it would be a common case to write `distance(predecesso
[STLExtras] Add distance() for ranges, pred_size(), and succ_size()
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
show more ...
|
#
2c864551 |
| 09-May-2018 |
Shiva Chen <shiva0217@gmail.com> |
[DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.
In order to set breakpoints on labels and list source code around labels, we need collect debug information for labels, i.e., label nam
[DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.
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
show more ...
|
#
781aa181 |
| 05-May-2018 |
Craig Topper <craig.topper@intel.com> |
Fix a bunch of places where operator-> was used directly on the return from dyn_cast.
Inspired by r331508, I did a grep and found these.
Mostly just change from dyn_cast to cast. Some cases also sh
Fix a bunch of places where operator-> was used directly on the return from 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
show more ...
|
#
5f8f34e4 |
| 01-May-2018 |
Adrian Prantl <aprantl@apple.com> |
Remove \brief commands from doxygen comments.
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 ar
Remove \brief commands from doxygen comments.
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
show more ...
|
#
210a29de |
| 27-Apr-2018 |
Adrian Prantl <aprantl@apple.com> |
Fix a bug in GlobalOpt's handling of DIExpressions.
This patch adds support for fragment expressions TryToShrinkGlobalToBoolean() which were previously just dropped.
Thanks to Reid Kleckner for pro
Fix a bug in GlobalOpt's handling of DIExpressions.
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
show more ...
|
Revision tags: llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2 |
|
#
2be39228 |
| 21-Mar-2018 |
David Blaikie <dblaikie@gmail.com> |
Fix a couple of layering violations in Transforms
Remove #include of Transforms/Scalar.h from Transform/Utils to fix layering.
Transforms depends on Transforms/Utils, not the other way around. So r
Fix a couple of layering violations in Transforms
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
show more ...
|