summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR
Commit message (Collapse)AuthorAgeFilesLines
...
* [ORE] Add diagnostics hotness thresholdBrian Gesiak2017-06-302-0/+8
| | | | | | | | | | | | | | | | | | | | Summary: Add an option to prevent diagnostics that do not meet a minimum hotness threshold from being output. When generating optimization remarks for large codebases with a ton of cold code paths, this option can be used to limit the optimization remark output at a reasonable size. Discussion of this change can be read here: http://lists.llvm.org/pipermail/llvm-dev/2017-June/114377.html Reviewers: anemet, davidxl, hfinkel Reviewed By: anemet Subscribers: qcolombet, javed.absar, fhahn, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D34867 llvm-svn: 306912
* [ORE] Remove old "diagnostic hotness" spellingBrian Gesiak2017-06-301-7/+0
| | | | | | | | | | | | | | | | | | | Summary: Depends on https://reviews.llvm.org/D34865. With the Clang uses of the old spelling having been removed in https://reviews.llvm.org/D34865, get rid of the old "diagnostic hotness" spellings in favor of the new "diagnostics hotness". Reviewers: anemet, davidxl Reviewed By: anemet Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D34866 llvm-svn: 306866
* [ORE] Unify spelling as "diagnostics hotness"Brian Gesiak2017-06-302-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: To enable profile hotness information in diagnostics output, Clang takes the option `-fdiagnostics-show-hotness` -- that's "diagnostics", with an "s" at the end. Clang also defines `CodeGenOptions::DiagnosticsWithHotness`. LLVM, on the other hand, defines `LLVMContext::getDiagnosticHotnessRequested` -- that's "diagnostic", not "diagnostics". It's a small difference, but it's confusing, typo-inducing, and frustrating. Add a new method with the spelling "diagnostics", and "deprecate" the old spelling. Reviewers: anemet, davidxl Reviewed By: anemet Subscribers: llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D34864 llvm-svn: 306848
* [Dominators] Do not perform expensive checks by default. Fix PR33656.Jakub Kuderski2017-06-301-1/+2
| | | | | | | | | | | | | | | | | | | Summary: Some transforms assume that DT.verifyDomInfo() is not expensive and call it even when ENABLE_EXPENSIVE_CHECKS is not set. This patch disables expensive Dominator Tree verification (reachability, parent property, sibling property) to fix [[ https://bugs.llvm.org/show_bug.cgi?id=33656 | PR33656 ]]. Note that this is only a temporary fix. Reviewers: dberlin, chapuni, kparzysz, grosser Reviewed By: dberlin Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D34894 llvm-svn: 306839
* [Dominators] Add parent and sibling property verification (non-hacky)Jakub Kuderski2017-06-291-2/+15
| | | | | | | | | | | | | | | | | | | Summary: This patch adds an additional level of verification - it checks parent and sibling properties of a tree. By definition, every tree with these two properties is a dominator tree. It is possible to run those check by running llvm with `-verify-dom-info=1`. Bootstrapping clang and building the llvm test suite with this option enabled doesn't yield any errors. Reviewers: dberlin, sanjoy, chandlerc Reviewed By: dberlin Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D34482 llvm-svn: 306711
* [Constants] Fix copy-pasto in llvm_unreachable message. NFCCraig Topper2017-06-271-1/+1
| | | | llvm-svn: 306456
* [IR] Rename BinaryOperator::init to AssertOK and remove argument. Replace ↵Craig Topper2017-06-261-6/+5
| | | | | | | | default case in switch with llvm_unreachable since all valid opcodes are covered. This method doesn't do any initializing. It just contains asserts. So renaming to AssertOK makes it consistent with similar instructions in other Instruction classes. llvm-svn: 306277
* [IR] Use isIntOrIntVectorTy instead of writing it out the long way. NFCCraig Topper2017-06-251-10/+4
| | | | llvm-svn: 306250
* Restrict the definition of loop preheader to avoid EH blocksAndrew Kaylor2017-06-221-0/+13
| | | | | | Differential Revision: https://reviews.llvm.org/D34487 llvm-svn: 306070
* Define behavior of "stack-probe-size" attribute when inlining.whitequark2017-06-221-2/+28
| | | | | | | | | | Also document the attribute, since "probe-stack" already is. Reviewed By: majnemer Differential Revision: https://reviews.llvm.org/D34528 llvm-svn: 306069
* [AVX-512] Remove and autoupgrade the masked integer compare intrinsicsCraig Topper2017-06-221-6/+33
| | | | | | | | | | | | | | | | | Summary: These intrinsics aren't used by clang and haven't been for a while. There's some really terrible codegen in the 32-bit target for avx512bw due to i64 not being legal. But as I said these intrinsics aren't used by clang even before this patch so this codegen reflects our clang behavior today. Reviewers: spatel, RKSimon, zvi, igorb Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D34389 llvm-svn: 306047
* Add a "probe-stack" attributewhitequark2017-06-211-0/+7
| | | | | | | | | | | | | This attribute is used to ensure the guard page is triggered on stack overflow. Stack frames larger than the guard page size will generate a call to __probestack to touch each page so the guard page won't be skipped. Reviewed By: majnemer Differential Revision: https://reviews.llvm.org/D34386 llvm-svn: 305939
* [Statepoint] Add helper functions for GCRelocate and GCResultAnna Thomas2017-06-201-0/+12
| | | | | | | These functions isGCRelocate and isGCResult are similar to isStatepoint(const Value*). llvm-svn: 305847
* [IR] Fix some Clang-tidy modernize-use-using warnings; other minor fixes (NFC).Eugene Zelenko2017-06-196-125/+232
| | | | llvm-svn: 305755
* [ConstantRange] Implement getSignedMin/Max in a less complicated and faster wayCraig Topper2017-06-161-15/+2
| | | | | | | | | | | | | | Summary: As far as I can tell we should be able to implement these almost the same way we do unsigned, but using signed comparisons and checks for min signed value instead of min unsigned value. Reviewers: pete, davide, sanjoy Reviewed By: davide Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33815 llvm-svn: 305607
* [Atomics] Rename and change prototype for atomic memcpy intrinsicDaniel Neilson2017-06-162-18/+28
| | | | | | | | | | | | | | | | | | Summary: Background: http://lists.llvm.org/pipermail/llvm-dev/2017-May/112779.html This change is to alter the prototype for the atomic memcpy intrinsic. The prototype itself is being changed to more closely resemble the semantics and parameters of the llvm.memcpy intrinsic -- to ease later combination of the llvm.memcpy and atomic memcpy intrinsics. Furthermore, the name of the atomic memcpy intrinsic is being changed to make it clear that it is not a generic atomic memcpy, but specifically a memcpy is unordered atomic. Reviewers: reames, sanjoy, efriedma Reviewed By: reames Subscribers: mzolotukhin, anna, llvm-commits, skatkov Differential Revision: https://reviews.llvm.org/D33240 llvm-svn: 305558
* [cfi] CFI-ICall for ThinLTO.Evgeniy Stepanov2017-06-161-2/+5
| | | | | | | | Implement ControlFlowIntegrity for indirect function calls in ThinLTO. Design follows the RFC in llvm-dev, see https://groups.google.com/d/msg/llvm-dev/MgUlaphu4Qc/kywu0AqjAQAJ llvm-svn: 305533
* Apply summary-based dead stripping to regular LTO modules with summaries.Peter Collingbourne2017-06-151-0/+10
| | | | | | | | | | | | | | | If a regular LTO module has a summary index, then instead of linking it into the combined regular LTO module right away, add it to the combined summary index and associate it with a special module that represents the combined regular LTO module. Any such modules are linked during LTO::run(), at which time we use the results of summary-based dead stripping to control whether to link prevailing symbols. Differential Revision: https://reviews.llvm.org/D33922 llvm-svn: 305482
* Align definition of DW_OP_plus with DWARF spec [3/3]Florian Hahn2017-06-142-12/+17
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch is part of 3 patches that together form a single patch, but must be introduced in stages in order not to break things. The way that LLVM interprets DW_OP_plus in DIExpression nodes is basically that of the DW_OP_plus_uconst operator since LLVM expects an unsigned constant operand. This unnecessarily restricts the DW_OP_plus operator, preventing it from being used to describe the evaluation of runtime values on the expression stack. These patches try to align the semantics of DW_OP_plus and DW_OP_minus with that of the DWARF definition, which pops two elements off the expression stack, performs the operation and pushes the result back on the stack. This is done in three stages: • The first patch (LLVM) adds support for DW_OP_plus_uconst. • The second patch (Clang) contains changes all its uses from DW_OP_plus to DW_OP_plus_uconst. • The third patch (LLVM) changes the semantics of DW_OP_plus and DW_OP_minus to be in line with its DWARF meaning. This patch includes the bitcode upgrade from legacy DIExpressions. Patch by Sander de Smalen. Reviewers: echristo, pcc, aprantl Reviewed By: aprantl Subscribers: fhahn, javed.absar, aprantl, llvm-commits Differential Revision: https://reviews.llvm.org/D33894 llvm-svn: 305386
* Align definition of DW_OP_plus with DWARF spec [1/3]Florian Hahn2017-06-131-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch is part of 3 patches that together form a single patch, but must be introduced in stages in order not to break things. The way that LLVM interprets DW_OP_plus in DIExpression nodes is basically that of the DW_OP_plus_uconst operator since LLVM expects an unsigned constant operand. This unnecessarily restricts the DW_OP_plus operator, preventing it from being used to describe the evaluation of runtime values on the expression stack. These patches try to align the semantics of DW_OP_plus and DW_OP_minus with that of the DWARF definition, which pops two elements off the expression stack, performs the operation and pushes the result back on the stack. This is done in three stages: • The first patch (LLVM) adds support for DW_OP_plus_uconst. • The second patch (Clang) contains changes all its uses from DW_OP_plus to DW_OP_plus_uconst. • The third patch (LLVM) changes the semantics of DW_OP_plus and DW_OP_minus to be in line with its DWARF meaning. This patch includes the bitcode upgrade from legacy DIExpressions. Patch by Sander de Smalen. Reviewers: pcc, echristo, aprantl Reviewed By: aprantl Subscribers: fhahn, aprantl, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D33892 llvm-svn: 305304
* [IR] Stop deleting other signatures of User::operator new when we override ↵Craig Topper2017-06-121-18/+0
| | | | | | | | | | | | | | | | | | one signature in a class derived from User User has 3 signatures for operator new today. They take a single size, a size and a number of users, and a size, number of users, and descriptor size. Historically there used to only be one signature that took size and a number of uses. Long ago derived classes implemented their own versions that took just a size and would call the size and use count version. Then they left an unimplemented signature for the size and use count signature from User. As we moved to C++11 this unimplemented signature because = delete. Since then operator new has picked up two new signatures for operator new. But when the 3 argument version was added it was never added to the delete list in all of the derived classes where the 2 argument version is deleted. This makes things inconsistent. I believe once one version of operator new is created in a derived class name hiding will take care of making all of the base class signatures unavailable. So I don't think the deleted lines are needed at all. This patch removes all of the deletes in cases where there is an override or there is already a delete of another signature (that should trigger name hiding too). Differential Revision: https://reviews.llvm.org/D34120 llvm-svn: 305251
* fix typos/formatting; NFCSanjay Patel2017-06-121-6/+3
| | | | llvm-svn: 305243
* IR: Replace the "Linker Options" module flag with "llvm.linker.options" ↵Peter Collingbourne2017-06-121-0/+8
| | | | | | | | | | named metadata. The new metadata is easier to manipulate than module flags. Differential Revision: https://reviews.llvm.org/D31349 llvm-svn: 305227
* [LoopVectorize] Don't preserve nsw/nuw flags on shrunken ops.George Burgess IV2017-06-091-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we're shrinking a binary operation, it may be the case that the new operations wraps where the old didn't. If this happens, the behavior should be well-defined. So, we can't always carry wrapping flags with us when we shrink operations. If we do, we get incorrect optimizations in cases like: void foo(const unsigned char *from, unsigned char *to, int n) { for (int i = 0; i < n; i++) to[i] = from[i] - 128; } which gets optimized to: void foo(const unsigned char *from, unsigned char *to, int n) { for (int i = 0; i < n; i++) to[i] = from[i] | 128; } Because: - InstCombine turned `sub i32 %from.i, 128` into `add nuw nsw i32 %from.i, 128`. - LoopVectorize vectorized the add to be `add nuw nsw <16 x i8>` with a vector full of `i8 128`s - InstCombine took advantage of the fact that the newly-shrunken add "couldn't wrap", and changed the `add` to an `or`. InstCombine seems happy to figure out whether we can add nuw/nsw on its own, so I just decided to drop the flags. There are already a number of places in LoopVectorize where we rely on InstCombine to clean up. llvm-svn: 305053
* [IR] Remove getNumSuccessorsV/getSuccessorV/setSuccessorV from the ↵Craig Topper2017-06-081-130/+3
| | | | | | | | | | | | TerminatorInst subclasses as much as possible now that Value has been de-virtualized These used to be virtual methods that would enable doing the right thing with only a TerminatorInst pointer. I believe they were also acting as vtable anchors in my cases. I think the fact that they had a separate name ending in V was to allow a version without V to be called without a virtual call in a pre-C++11 final keyword world. Where possible the base methods in TerminatorInst dispatch directly to the public methods in the classes that have the same signature. For some classes this wasn't possible so I've left private method versions that match the name and signature of the version in TerminatorInst. All versions have been moved into the class definitions since we no longer need vtable anchors here. Differential Revision: https://reviews.llvm.org/D34011 llvm-svn: 305028
* Move Object format code to lib/BinaryFormat.Zachary Turner2017-06-075-5/+5
| | | | | | | | | | | | This creates a new library called BinaryFormat that has all of the headers from llvm/Support containing structure and layout definitions for various types of binary formats like dwarf, coff, elf, etc as well as the code for identifying a file from its magic. Differential Revision: https://reviews.llvm.org/D33843 llvm-svn: 304864
* [Constants] Use isUIntN/isIntN from MathExtras instead of reimplementing the ↵Craig Topper2017-06-071-9/+2
| | | | | | same code. NFC llvm-svn: 304856
* [Constants] Use APInt::isNullValue/isOneValue/uge to simplify some code and ↵Craig Topper2017-06-071-1/+1
| | | | | | take advantage of APInt optimizations. NFC llvm-svn: 304855
* [Atomics][LoopIdiom] Recognize unordered atomic memcpyAnna Thomas2017-06-061-0/+32
| | | | | | | | | | | | | | | | | | | | | | Summary: Expanding the loop idiom test for memcpy to also recognize unordered atomic memcpy. The only difference for recognizing an unordered atomic memcpy and instead of a normal memcpy is that the loads and/or stores involved are unordered atomic operations. Background: http://lists.llvm.org/pipermail/llvm-dev/2017-May/112779.html Patch by Daniel Neilson! Reviewers: reames, anna, skatkov Reviewed By: reames, anna Subscribers: llvm-commits, mzolotukhin Differential Revision: https://reviews.llvm.org/D33243 llvm-svn: 304806
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-0624-36/+36
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* [llvm] Remove double semicolonsMandeep Singh Grang2017-06-061-1/+1
| | | | | | | | | | | | Reviewers: craig.topper, arsenm, mehdi_amini Reviewed By: mehdi_amini Subscribers: mehdi_amini, wdng, nhaehnle, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D33924 llvm-svn: 304767
* [ConstantRange] Remove costly udivrem from ConstantRange::truncateCraig Topper2017-06-051-15/+19
| | | | | | | | | | | | Truncate currently uses a udivrem call which is going to be slow particularly for larger than 64-bit widths. As far as I can tell all we were trying to do was modulo LowerDiv by (MaxValue+1) and make sure whatever value was effectively subtracted from LowerDiv was also subtracted from UpperDiv. This patch recognizes that MaxValue+1 is a power of 2 so we can just use a bitwise AND to accomplish a modulo operation or isolate the upper bits. Differential Revision: https://reviews.llvm.org/D32672 llvm-svn: 304733
* Handle non-unique edges in edge-dominanceAdam Nemet2017-06-051-13/+7
| | | | | | | | | | | | | | | | | | | | | | | | This removes a quadratic behavior in assert-enabled builds. GVN propagates the equivalence from a condition into the blocks guarded by the condition. E.g. for 'if (a == 7) { ... }', 'a' will be replaced in the block with 7. It does this by replacing all the uses of 'a' that are dominated by the true edge. For a switch with N cases and U uses of the value, this will mean N * U calls to 'dominates'. Asserting isSingleEdge in 'dominates' make this N^2 * U because this function checks for the uniqueness of the edge. I.e. traverses each edge between the SwitchInst's block and the cases. The change removes the assert and makes 'dominates' works correctly in the presence of non-unique edges. This brings build time down by an order of magnitude for an input that has ~10k cases in a switch statement. Differential Revision: https://reviews.llvm.org/D33584 llvm-svn: 304721
* [LLVM-C] [OCaml] Expose Type::subtypes.whitequark2017-06-051-0/+12
| | | | | | | | | | | | | The C functions added are LLVMGetNumContainedTypes and LLVMGetSubtypes. The OCaml function added is Llvm.subtypes. Patch by Ekaterina Vaartis. Differential Revision: https://reviews.llvm.org/D33677 llvm-svn: 304709
* IR: When creating a global variable, assert that its type is valid.Peter Collingbourne2017-06-041-0/+4
| | | | llvm-svn: 304690
* Reapply "[Cloning] Take another pass at properly cloning debug info"Keno Fischer2017-06-011-81/+0
| | | | | | | | This was rL304226, reverted in 304228 due to a clang assertion failure on the build bots. That problem should have been addressed by clang commit rL304470. llvm-svn: 304488
* Add opt-bisect support for region passes.Eli Friedman2017-06-011-3/+12
| | | | | | | | This is necessary to get opt-bisect working with polly. Differential Revision: https://reviews.llvm.org/D33751 llvm-svn: 304476
* [DIBuilder] Add a more fine-grained finalization methodKeno Fischer2017-06-011-16/+17
| | | | | | | | | | | | | | | | | | | | Summary: Clang wants to clone a function before it is done building the entire compilation unit. As of now, there is no good way to do that, because CloneFunction doesn't like dealing with temporary metadata. However, as long as clang doesn't want to add any variables to this SP, it should be fine to just prematurely finalize it. Add an API to allow this. This is done in preparation of a clang commit to fix the assertion that necessitated the revert of D33655. Reviewers: aprantl, dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33704 llvm-svn: 304467
* [IR] Add additional addParamAttr/removeParamAttr to AttributeList APIReid Kleckner2017-05-313-30/+107
| | | | | | | | | | | | | | | | | | | Summary: Fairly straightforward patch to fill in some of the holes in the attributes API with respect to accessing parameter/argument attributes. The patch aims to step further towards encapsulating the idx+FirstArgIndex pattern to access these attributes to within the AttributeList. Patch by Daniel Neilson! Reviewers: rnk, chandlerc, pete, javed.absar, reames Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33355 llvm-svn: 304329
* Revert "[Atomics][LoopIdiom] Recognize unordered atomic memcpy"Anna Thomas2017-05-311-32/+0
| | | | | | | | | | This reverts commit r304310. It caused build failures in polly and mingw due to undefined reference to llvm::RTLIB::getMEMCPY_ELEMENT_ATOMIC. llvm-svn: 304315
* [Atomics][LoopIdiom] Recognize unordered atomic memcpyAnna Thomas2017-05-311-0/+32
| | | | | | | | | | | | | | | | | | | | | Summary: Expanding the loop idiom test for memcpy to also recognize unordered atomic memcpy. The only difference for recognizing an unordered atomic memcpy and instead of a normal memcpy is that the loads and/or stores involved are unordered atomic operations. Background: http://lists.llvm.org/pipermail/llvm-dev/2017-May/112779.html Patch by Daniel Neilson! Reviewers: reames, anna, skatkov Reviewed By: reames Subscribers: llvm-commits, mzolotukhin Differential Revision: https://reviews.llvm.org/D33243 llvm-svn: 304310
* Fix assertion when merging multiple empty AttributeListsReid Kleckner2017-05-311-0/+4
| | | | | | | | Patch by Nicholas Wilson! Differential Revision: https://reviews.llvm.org/D33627 llvm-svn: 304300
* Revert "[Cloning] Take another pass at properly cloning debug info"Keno Fischer2017-05-301-0/+81
| | | | | | At least one build bot is complaining. Will investigate after lunch. llvm-svn: 304228
* [Cloning] Take another pass at properly cloning debug infoKeno Fischer2017-05-301-81/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In rL302576, DISubprograms gained the constraint that a !dbg attachments to functions must have a 1:1 mapping to DISubprograms. As part of that change, the function cloning support was adjusted to attempt to enforce this invariant during cloning. However, there were several problems with the implementation. Part of these were fixed in rL304079. However, there was a more fundamental problem with these changes, namely that it bypasses the matadata value map, causing the cloned metadata to be a mix of metadata pointing to the new suprogram (where manual code was added to fix those up) and the old suprogram (where this was not the case). This mismatch could cause a number of different assertion failures in the DWARF emitter. Some of these are given at https://github.com/JuliaLang/julia/issues/22069, but some others have been observed as well. Attempt to rectify this by partially reverting the manual DI metadata fixup, and instead using the standard value map approach. To retain the desired semantics of not duplicating the compilation unit and inlined subprograms, explicitly freeze these in the value map. Reviewers: dblaikie, aprantl, GorNishanov, echristo Reviewed By: aprantl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33655 llvm-svn: 304226
* Cloning: Fix debug info cloningGor Nishanov2017-05-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: I believe https://reviews.llvm.org/rL302576 introduced two bugs: 1) it produces duplicate distinct variables for every: dbg.value describing the same variable. To fix the problme I switched form getDistinct() to get() in DebugLoc.cpp: auto reparentVar = [&](DILocalVariable *Var) { return DILocalVariable::getDistinct( 2) It passes NewFunction plain name as a linkagename parameter to Subprogram constructor. Breaks assert in: || DeclLinkageName.empty()) || LinkageName == DeclLinkageName) && "decl has a linkage name and it is different"' failed. #9 0x00007f5010261b75 llvm::DwarfUnit::applySubprogramDefinitionAttributes(llvm::DISubprogram const*, llvm::DIE&) /home/gor/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp:1173:3 # (Edit: reproducer added) Here how https://reviews.llvm.org/rL302576 broke coroutine debug info. Coroutine body of the original function is split into several parts by cloning and removing unneeded code. All parts describe the original function and variables present in the original function. For a simple case, prior to Split, original function has these two blocks: ``` PostSpill: ; preds = %AllocaSpillBB call void @llvm.dbg.value(metadata i32 %x, i64 0, metadata !14, metadata !15), !dbg !13 store i32 %x, i32* %x.addr, align 4 ... and sw.epilog: ; preds = %sw.bb %x.addr.reload.addr = getelementptr inbounds %f.Frame, %f.Frame* %FramePtr, i32 0, i32 4, !dbg !20 %4 = load i32, i32* %x.addr.reload.addr, align 4, !dbg !20 call void @llvm.dbg.value(metadata i32 %4, i64 0, metadata !14, metadata !15), !dbg !13 !14 = !DILocalVariable(name: "x", arg: 1, scope: !6, file: !7, line: 55, type: !11) ``` Note that in two blocks different expression represent the same original user variable X. Before rL302576, for every cloned function there was exactly one cloned DILocalVariable(name: "x" as in: ``` define i8* @f(i32 %x) #0 !dbg !6 { ... !6 = distinct !DISubprogram(name: "f", scope: !7, file: !7, line: 55, type: !8, isLocal: false, isDefinition: true, scopeLine: 55, flags: DIFlagPrototyped, ... !14 = !DILocalVariable(name: "x", arg: 1, scope: !6, file: !7, line: 55, type: !11) define internal fastcc void @f.resume(%f.Frame* %FramePtr) #0 !dbg !25 { ... !25 = distinct !DISubprogram(name: "f", scope: !7, file: !7, line: 55, type: !8, isLocal: false, isDefinition: true, scopeLine: 55, flags: DIFlagPrototyped, isOptimized: false, unit: !0, variables: !2) !28 = !DILocalVariable(name: "x", arg: 1, scope: !25, file: !7, line: 55, type: !11) ``` After rL302576, for every cloned function there were as many DILocalVariable(name: "x" as there were "call void @llvm.dbg.value" for that variable. This was causing asserts in VerifyDebugInfo and AssemblyPrinter. Example: ``` !27 = distinct !DISubprogram(name: "f", linkageName: "f.resume", scope: !7, file: !7, line: 55, type: !8, isLocal: false, isDefinition: true, scopeLine: 55, !29 = distinct !DILocalVariable(name: "x", arg: 1, scope: !27, file: !7, line: 55, type: !11) !39 = distinct !DILocalVariable(name: "x", arg: 1, scope: !27, file: !7, line: 55, type: !11) !41 = distinct !DILocalVariable(name: "x", arg: 1, scope: !27, file: !7, line: 55, type: !11) ``` Second problem: Prior to rL302576, all clones were described by DISubprogram referring to original function. ``` define i8* @f(i32 %x) #0 !dbg !6 { ... !6 = distinct !DISubprogram(name: "f", scope: !7, file: !7, line: 55, type: !8, isLocal: false, isDefinition: true, scopeLine: 55, flags: DIFlagPrototyped, define internal fastcc void @f.resume(%f.Frame* %FramePtr) #0 !dbg !25 { ... !25 = distinct !DISubprogram(name: "f", scope: !7, file: !7, line: 55, type: !8, isLocal: false, isDefinition: true, scopeLine: 55, flags: DIFlagPrototyped, ``` After rL302576, DISubprogram for clones is of two minds, plain name refers to the original name, linkageName refers to plain name of the clone. ``` !27 = distinct !DISubprogram(name: "f", linkageName: "f.resume", scope: !7, file: !7, line: 55, type: !8, isLocal: false, isDefinition: true, scopeLine: 55, ``` I think the assumption in AsmPrinter is that both name and linkageName should refer to the same entity. It asserts here when they are not: ``` || DeclLinkageName.empty()) || LinkageName == DeclLinkageName) && "decl has a linkage name and it is different"' failed. #9 0x00007f5010261b75 llvm::DwarfUnit::applySubprogramDefinitionAttributes(llvm::DISubprogram const*, llvm::DIE&) /home/gor/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp:1173:3 ``` After this fix, behavior (with respect to coroutines) reverts to exactly as it was before and therefore making them debuggable again, or even more importantly, compilable, with "-g" Reviewers: dblaikie, echristo, aprantl Reviewed By: dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33614 llvm-svn: 304079
* [IR] Add an iterator and range accessor for the PHI nodes of a basicChandler Carruth2017-05-261-7/+9
| | | | | | | | | | | | | | | | | block. This allows writing much more natural and readable range based for loops directly over the PHI nodes. It also takes advantage of the same tricks for terminating the sequence as the hand coded versions. I've replaced one example of this mostly to showcase the difference and I've added a unit test to make sure the facilities really work the way they're intended. I want to use this inside of SimpleLoopUnswitch but it seems generally nice. Differential Revision: https://reviews.llvm.org/D33533 llvm-svn: 303964
* Add constrained intrinsics for some libm-equivalent operationsAndrew Kaylor2017-05-252-3/+42
| | | | | | Differential revision: https://reviews.llvm.org/D32319 llvm-svn: 303922
* Silence MSVC warning about unsigned integer overflow, which has defined behaviorReid Kleckner2017-05-231-1/+3
| | | | llvm-svn: 303693
* Commit AttributeList change that was supposed to be part of r303654Reid Kleckner2017-05-231-2/+2
| | | | llvm-svn: 303656
* [IR] Switch AttributeList to use an array for O(1) accessReid Kleckner2017-05-234-278/+183
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
OpenPOWER on IntegriCloud