Revision tags: llvmorg-8.0.0-rc1 |
|
#
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <chandlerc@gmail.com> |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository.
llvm-svn: 351636
show more ...
|
#
b264d69d |
| 21-Dec-2018 |
Vedant Kumar <vsk@apple.com> |
[IR] Add Instruction::isLifetimeStartOrEnd, NFC
Instruction::isLifetimeStartOrEnd() checks whether an Instruction is an llvm.lifetime.start or an llvm.lifetime.end intrinsic.
This was suggested as
[IR] Add Instruction::isLifetimeStartOrEnd, NFC
Instruction::isLifetimeStartOrEnd() checks whether an Instruction is an llvm.lifetime.start or an llvm.lifetime.end intrinsic.
This was suggested as a cleanup in D55967.
Differential Revision: https://reviews.llvm.org/D56019
llvm-svn: 349964
show more ...
|
#
978ba615 |
| 20-Dec-2018 |
Michael Kruse <llvm@meinersbur.de> |
Introduce llvm.loop.parallel_accesses and llvm.access.group metadata.
The current llvm.mem.parallel_loop_access metadata has a problem in that it uses LoopIDs. LoopID unfortunately is not loop ident
Introduce llvm.loop.parallel_accesses and llvm.access.group metadata.
The current llvm.mem.parallel_loop_access metadata has a problem in that it uses LoopIDs. LoopID unfortunately is not loop identifier. It is neither unique (there's even a regression test assigning the some LoopID to multiple loops; can otherwise happen if passes such as LoopVersioning make copies of entire loops) nor persistent (every time a property is removed/added from a LoopID's MDNode, it will also receive a new LoopID; this happens e.g. when calling Loop::setLoopAlreadyUnrolled()). Since most loop transformation passes change the loop attributes (even if it just to mark that a loop should not be processed again as llvm.loop.isvectorized does, for the versioned and unversioned loop), the parallel access information is lost for any subsequent pass.
This patch unlinks LoopIDs and parallel accesses. llvm.mem.parallel_loop_access metadata on instruction is replaced by llvm.access.group metadata. llvm.access.group points to a distinct MDNode with no operands (avoiding the problem to ever need to add/remove operands), called "access group". Alternatively, it can point to a list of access groups. The LoopID then has an attribute llvm.loop.parallel_accesses with all the access groups that are parallel (no dependencies carries by this loop).
This intentionally avoid any kind of "ID". Loops that are clones/have their attributes modifies retain the llvm.loop.parallel_accesses attribute. Access instructions that a cloned point to the same access group. It is not necessary for each access to have it's own "ID" MDNode, but those memory access instructions with the same behavior can be grouped together.
The behavior of llvm.mem.parallel_loop_access is not changed by this patch, but should be considered deprecated.
Differential Revision: https://reviews.llvm.org/D52116
llvm-svn: 349725
show more ...
|
#
9d182733 |
| 15-Dec-2018 |
Vedant Kumar <vsk@apple.com> |
[Util] Refer to [s|z]exts of args when converting dbg.declares (fix PR35400)
When converting dbg.declares, if the described value is a [s|z]ext, refer to the ext directly instead of referring to its
[Util] Refer to [s|z]exts of args when converting dbg.declares (fix PR35400)
When converting dbg.declares, if the described value is a [s|z]ext, refer to the ext directly instead of referring to its operand.
This fixes a narrowing bug (the debugger got the sign of a variable wrong, see llvm.org/PR35400).
The main reason to refer to the ext's operand was that an optimization may remove the ext itself, leading to a dropped variable. Now that InstCombine has been taught to use replaceAllDbgUsesWith (r336451), this is less of a concern. Other passes can/should adopt this API as needed to fix dropped variable bugs.
Differential Revision: https://reviews.llvm.org/D51813
llvm-svn: 349214
show more ...
|
#
5948b7f3 |
| 14-Dec-2018 |
Michael Kruse <llvm@meinersbur.de> |
[Transforms] Preserve metadata when converting invoke to call.
The `changeToCall` function did not preserve the invoke's metadata. Currently, there is probably no metadata that depends on being appl
[Transforms] Preserve metadata when converting invoke to call.
The `changeToCall` function did not preserve the invoke's metadata. Currently, there is probably no metadata that depends on being applied on a CallInst or InvokeInst. Therefore we can replace the instruction's metadata.
This fixes http://llvm.org/PR39994
Suggested-by: Moritz Kreutzer <moritz.kreutzer@siemens.com>
Differential Revision: https://reviews.llvm.org/D55666
llvm-svn: 349170
show more ...
|
#
8ec7709f |
| 10-Dec-2018 |
Davide Italiano <davide@freebsd.org> |
[Local] Promote an utility that could be used elsewhere. NFCI.
llvm-svn: 348804
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3 |
|
#
4de31bba |
| 19-Nov-2018 |
Vedant Kumar <vsk@apple.com> |
[IR] Add hasNPredecessors, hasNPredecessorsOrMore to BasicBlock
Add methods to BasicBlock which make it easier to efficiently check whether a block has N (or more) predecessors.
This can be more ef
[IR] Add hasNPredecessors, hasNPredecessorsOrMore to BasicBlock
Add methods to BasicBlock which make it easier to efficiently check whether a block has N (or more) predecessors.
This can be more efficient than using pred_size(), which is a linear time operation.
We might consider adding similar methods for successors. I haven't done so in this patch because succ_size() is already O(1).
With this patch applied, I measured a 0.065% compile-time reduction in user time for running `opt -O3` on the sqlite3 amalgamation (30 trials). The change in mergeStoreIntoSuccessor alone saves 45 million linked list iterations in a stage2 Release build of llc.
See llvm.org/PR39702 for a harder but more general way of achieving similar results.
Differential Revision: https://reviews.llvm.org/D54686
llvm-svn: 347256
show more ...
|
Revision tags: llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1 |
|
#
fc7654a6 |
| 27-Oct-2018 |
Florian Hahn <florian.hahn@arm.com> |
[Local] Keep K's range if K does not move when combining metadata.
As K has to dominate I, IIUC I's range metadata must be a subset of K's. After Eli's recent clarification to the LangRef, loading a
[Local] Keep K's range if K does not move when combining metadata.
As K has to dominate I, IIUC I's range metadata must be a subset of K's. After Eli's recent clarification to the LangRef, loading a value outside of the range is undefined behavior. Therefore if I's range contains elements outside of K's range and we would load one such value, K would cause undefined behavior.
In cases like hoisting/sinking, we still want the most generic range over all code paths to/from the hoist/sink point. As suggested in the patches related to D47339, I will refactor the handling of those scenarios and try to decouple it from this function as follow up, once we switched to a similar handling of metadata in most of combineMetadata.
I updated some tests checking mostly the merging of metadata to keep the metadata of to dominating load. The most interesting one is probably test8 in test/Transforms/JumpThreading/thread-loads.ll. It contained a comment about the alias metadata preventing us to eliminate the branch, but it seem like the actual problem currently is that we merge the ranges of both loads and cannot eliminate the icmp afterwards. With this patch, we manage to eliminate the icmp, as the range of the first load excludes 8.
Reviewers: efriedma, nlopes, davide
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D51629
llvm-svn: 345456
show more ...
|
#
9a24e1a7 |
| 25-Oct-2018 |
Carlos Alberto Enciso <carlos.alberto.enciso@gmail.com> |
[DebugInfo][Dexter] Unreachable line stepped onto after SimplifyCFG.
When SimplifyCFG changes the PHI node into a select instruction, the debug line records becomes ambiguous. It causes the debugger
[DebugInfo][Dexter] Unreachable line stepped onto after SimplifyCFG.
When SimplifyCFG changes the PHI node into a select instruction, the debug line records becomes ambiguous. It causes the debugger to display unreachable source lines.
Differential Revision: https://reviews.llvm.org/D53287
llvm-svn: 345250
show more ...
|
#
c8eaea71 |
| 18-Oct-2018 |
Chandler Carruth <chandlerc@gmail.com> |
[TI removal] Use `Instruction` instead of `TerminatorInst` for a variable's type.
llvm-svn: 344717
|
#
edb12a83 |
| 15-Oct-2018 |
Chandler Carruth <chandlerc@gmail.com> |
[TI removal] Make variables declared as `TerminatorInst` and initialized by `getTerminator()` calls instead be declared as `Instruction`.
This is the biggest remaining chunk of the usage of `getTerm
[TI removal] Make variables declared as `TerminatorInst` and initialized by `getTerminator()` calls instead be declared as `Instruction`.
This is the biggest remaining chunk of the usage of `getTerminator()` that insists on the narrow type and so is an easy batch of updates. Several files saw more extensive updates where this would cascade to requiring API updates within the file to use `Instruction` instead of `TerminatorInst`. All of these were trivial in nature (pervasively using `Instruction` instead just worked).
llvm-svn: 344502
show more ...
|
#
c0952c8a |
| 10-Oct-2018 |
Carlos Alberto Enciso <carlos.alberto.enciso@gmail.com> |
Revert "[DebugInfo][Dexter] Unreachable line stepped onto after SimplifyCFG."
This reverts commit r344120.
It was causing buildbot failures.
llvm-svn: 344135
|
#
e7a347e5 |
| 10-Oct-2018 |
Carlos Alberto Enciso <carlos.alberto.enciso@gmail.com> |
[DebugInfo][Dexter] Unreachable line stepped onto after SimplifyCFG.
When SimplifyCFG changes the PHI node into a select instruction, the debug line records becomes ambiguous. It causes the debugger
[DebugInfo][Dexter] Unreachable line stepped onto after SimplifyCFG.
When SimplifyCFG changes the PHI node into a select instruction, the debug line records becomes ambiguous. It causes the debugger to display unreachable source lines.
Differential Revision: https://reviews.llvm.org/D52887
llvm-svn: 344120
show more ...
|
#
ba4e437c |
| 19-Sep-2018 |
Carlos Alberto Enciso <carlos.alberto.enciso@gmail.com> |
[DebugInfo][Dexter] Speculated BB presents illegal variable value to debugger.
When SimplifyCFG changes the PHI node into a select instruction, the debug information becomes ambiguous. It causes th
[DebugInfo][Dexter] Speculated BB presents illegal variable value to debugger.
When SimplifyCFG changes the PHI node into a select instruction, the debug information becomes ambiguous. It causes the debugger to display wrong variable value.
Differential Revision: https://reviews.llvm.org/D51976
llvm-svn: 342527
show more ...
|
Revision tags: llvmorg-7.0.0, llvmorg-7.0.0-rc3 |
|
#
9ae926b9 |
| 26-Aug-2018 |
Chandler Carruth <chandlerc@gmail.com> |
[IR] Replace `isa<TerminatorInst>` with `isTerminator()`.
This is a bit awkward in a handful of places where we didn't even have an instruction and now we have to see if we can build one. But on the
[IR] Replace `isa<TerminatorInst>` with `isTerminator()`.
This is a bit awkward in a handful of places where we didn't even have an instruction and now we have to see if we can build one. But on the whole, this seems like a win and at worst a reasonable cost for removing `TerminatorInst`.
All of this is part of the removal of `TerminatorInst` from the `Instruction` type hierarchy.
llvm-svn: 340701
show more ...
|
#
96fc1de7 |
| 26-Aug-2018 |
Chandler Carruth <chandlerc@gmail.com> |
[IR] Begin removal of TerminatorInst by removing successor manipulation.
The core get and set routines move to the `Instruction` class. These routines are only valid to call on instructions which ar
[IR] Begin removal of TerminatorInst by removing successor manipulation.
The core get and set routines move to the `Instruction` class. These routines are only valid to call on instructions which are terminators.
The iterator and *generic* range based access move to `CFG.h` where all the other generic successor and predecessor access lives. While moving the iterator here, simplify it using the iterator utilities LLVM provides and updates coding style as much as reasonable. The APIs remain pointer-heavy when they could better use references, and retain the odd behavior of `operator*` and `operator->` that is common in LLVM iterators. Adjusting this API, if desired, should be a follow-up step.
Non-generic range iteration is added for the two instructions where there is an especially easy mechanism and where there was code attempting to use the range accessor from a specific subclass: `indirectbr` and `br`. In both cases, the successors are contiguous operands and can be easily iterated via the operand list.
This is the first major patch in removing the `TerminatorInst` type from the IR's instruction type hierarchy. This change was discussed in an RFC here and was pretty clearly positive: http://lists.llvm.org/pipermail/llvm-dev/2018-May/123407.html
There will be a series of much more mechanical changes following this one to complete this move.
Differential Revision: https://reviews.llvm.org/D47467
llvm-svn: 340698
show more ...
|
#
406f1ff1 |
| 24-Aug-2018 |
Florian Hahn <florian.hahn@arm.com> |
[Local] Make DoesKMove required for combineMetadata.
This patch makes the DoesKMove argument non-optional, to force people to think about it. Most cases where it is false are either code hoisting or
[Local] Make DoesKMove required for combineMetadata.
This patch makes the DoesKMove argument non-optional, to force people to think about it. Most cases where it is false are either code hoisting or code sinking, where we pick one instruction from a set of equal instructions among different code paths.
Reviewers: dberlin, nlopes, efriedma, davide
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D47475
llvm-svn: 340606
show more ...
|
Revision tags: llvmorg-7.0.0-rc2 |
|
#
2ab544bc |
| 16-Aug-2018 |
Alina Sbirlea <asbirlea@google.com> |
Update MemorySSA in Local utils removing blocks.
Summary: Extend Local utils to update MemorySSA.
Subscribers: sanjoy, jlebar, Prazek, george.burgess.iv, llvm-commits
Differential Revision: https:
Update MemorySSA in Local utils removing blocks.
Summary: Extend Local utils to update MemorySSA.
Subscribers: sanjoy, jlebar, Prazek, george.burgess.iv, llvm-commits
Differential Revision: https://reviews.llvm.org/D48790
llvm-svn: 339951
show more ...
|
#
52d52834 |
| 07-Aug-2018 |
Anastasis Grammenos <anastasis.gramm2@gmail.com> |
[Local] Add dbg location on unreachable inst in changeToUnreachable
As show in https://bugs.llvm.org/show_bug.cgi?id=37960 it would be desirable to have debug location in the unreachable instruction
[Local] Add dbg location on unreachable inst in changeToUnreachable
As show in https://bugs.llvm.org/show_bug.cgi?id=37960 it would be desirable to have debug location in the unreachable instruction.
Also adds a unti test for this function.
Differential Revision: https://reviews.llvm.org/D50340
llvm-svn: 339173
show more ...
|
#
950576bd |
| 07-Aug-2018 |
Florian Hahn <florian.hahn@arm.com> |
[GVN,NewGVN] Keep nonnull if K does not move.
In combineMetadata, we should be able to preserve K's nonnull metadata, if K does not move. This condition should hold for all replacements by NewGVN/GV
[GVN,NewGVN] Keep nonnull if K does not move.
In combineMetadata, we should be able to preserve K's nonnull metadata, if K does not move. This condition should hold for all replacements by NewGVN/GVN, but I added a bunch of assertions to verify that.
Fixes PR35038.
There probably are additional kinds of metadata that could be preserved using similar reasoning. This is follow-up work.
Reviewers: dberlin, davide, efriedma, nlopes
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D47339
llvm-svn: 339149
show more ...
|
#
39bbe179 |
| 07-Aug-2018 |
Florian Hahn <florian.hahn@arm.com> |
[GVN,NewGVN] Move patchReplacementInstruction to Utils/Local.h
This function is shared between both implementations. I am not sure if Utils/Local.h is the best place though.
Reviewers: davide, dber
[GVN,NewGVN] Move patchReplacementInstruction to Utils/Local.h
This function is shared between both implementations. I am not sure if Utils/Local.h is the best place though.
Reviewers: davide, dberlin, efriedma, xbolva00
Reviewed By: efriedma, xbolva00
Differential Revision: https://reviews.llvm.org/D47337
llvm-svn: 339138
show more ...
|
#
ef72e481 |
| 06-Aug-2018 |
Hsiangkai Wang <hsiangkai@gmail.com> |
[DebugInfo] Refactor DbgInfoIntrinsic class hierarchy.
In the past, DbgInfoIntrinsic has a strong assumption that these intrinsics all have variables and expressions attached to them. However, it is
[DebugInfo] Refactor DbgInfoIntrinsic class hierarchy.
In the past, DbgInfoIntrinsic has a strong assumption that these intrinsics all have variables and expressions attached to them. However, it is too strong to derive the class for other debug entities. Now, it has problems for debug labels.
In order to make DbgInfoIntrinsic as a base class for 'debug info', I create a class for 'variable debug info', DbgVariableIntrinsic.
DbgDeclareInst, DbgAddrIntrinsic, and DbgValueInst will be derived from it.
Differential Revision: https://reviews.llvm.org/D50220
llvm-svn: 338984
show more ...
|
#
53048437 |
| 03-Aug-2018 |
Chijun Sima <simachijun@gmail.com> |
[Dominators] Make RemoveUnreachableBlocks return false if the BasicBlock is already awaiting deletion
Summary: Previously, `removeUnreachableBlocks` still returns true (which indicates the CFG is ch
[Dominators] Make RemoveUnreachableBlocks return false if the BasicBlock is already awaiting deletion
Summary: Previously, `removeUnreachableBlocks` still returns true (which indicates the CFG is changed) even when all the unreachable blocks found is awaiting deletion in the DDT class. This makes code pattern like ``` // Code modified from lib/Transforms/Scalar/SimplifyCFGPass.cpp bool EverChanged = removeUnreachableBlocks(F, nullptr, DDT); ... do { EverChanged = someMightHappenModifications(); EverChanged |= removeUnreachableBlocks(F, nullptr, DDT); } while (EverChanged); ``` become a dead loop. Fix this by detecting whether a BasicBlock is already awaiting deletion.
Reviewers: kuhar, brzycki, dmgreen, grosser, davide
Reviewed By: kuhar, brzycki
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D49738
llvm-svn: 338882
show more ...
|
Revision tags: llvmorg-7.0.0-rc1 |
|
#
21a8b605 |
| 03-Aug-2018 |
Chijun Sima <simachijun@gmail.com> |
[Dominators] Convert existing passes and utils to use the DomTreeUpdater class
Summary: This patch is the second in a series of patches related to the [[ http://lists.llvm.org/pipermail/llvm-dev/201
[Dominators] Convert existing passes and utils to use the DomTreeUpdater class
Summary: This patch is the second in a series of patches related to the [[ http://lists.llvm.org/pipermail/llvm-dev/2018-June/123883.html | RFC - A new dominator tree updater for LLVM ]].
It converts passes (e.g. adce/jump-threading) and various functions which currently accept DDT in local.cpp and BasicBlockUtils.cpp to use the new DomTreeUpdater class. These converted functions in utils can accept DomTreeUpdater with either UpdateStrategy and can deal with both DT and PDT held by the DomTreeUpdater.
Reviewers: brzycki, kuhar, dmgreen, grosser, davide
Reviewed By: brzycki
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D48967
llvm-svn: 338814
show more ...
|
#
b572f642 |
| 26-Jul-2018 |
Vedant Kumar <vsk@apple.com> |
[DebugInfo] LowerDbgDeclare: Add derefs when handling CallInst users
LowerDbgDeclare inserts a dbg.value before each use of an address described by a dbg.declare. When inserting a dbg.value before a
[DebugInfo] LowerDbgDeclare: Add derefs when handling CallInst users
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
show more ...
|