Change the default constructor to create invalid object.
The target will have to properly initialize the register banks before
using them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265460 91177308-0d34-0410-b5e6-96231b3b80d8
These were `protected` before, but might as well be `private`. Also
marked the classes themselves `final`.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265458 91177308-0d34-0410-b5e6-96231b3b80d8
This commit completely rewrites Mapper::mapMetadata (the implementation
of llvm::MapMetadata) using an iterative algorithm. The guts of the new
algorithm are in MDNodeMapper::map, the entry function in a new class.
Previously, Mapper::mapMetadata performed a recursive exploration of the
graph with eager "just in case there's a reason" malloc traffic.
The new algorithm has these benefits:
- New nodes and temporaries are not created eagerly.
- Uniquing cycles are not duplicated (see new unit test).
- No recursion.
Given a node to map, it does this:
1. Use a worklist to perform a post-order traversal of the transitively
referenced unmapped nodes.
2. Track which nodes will change operands, and which will have new
addresses in the mapped scheme. Propagate the changes through the
POT until fixed point, to pick up uniquing cycles that need to
change.
3. Map all the distinct nodes without touching their operands. If
RF_MoveDistinctMetadata, they get mapped to themselves; otherwise,
they get mapped to clones.
4. Map the uniqued nodes (bottom-up), lazily creating temporaries for
forward references as needed.
5. Remap the operands of the distinct nodes.
Mehdi helped me out by profiling this with -flto=thin. On his workload
(importing/etc. for opt.cpp), MapMetadata sped up by 15%, contributed
about 50% less to persistent memory, and made about 100x fewer calls to
malloc. The speedup is less than I'd hoped. The profile mainly blames
DenseMap lookups; perhaps there's a way to reduce them (e.g., by
disallowing remapping of MDString).
It would be nice to break the strange remaining recursion on the Value
side: MapValue => materializeInitFor => RemapInstruction => MapValue. I
think we could do this by having materializeInitFor return a worklist of
things to be remapped.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265456 91177308-0d34-0410-b5e6-96231b3b80d8
To start with, handle DW_FORM_string names. Follow up commit will handle
the interesting quirk with type units I was originally aiming for here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265452 91177308-0d34-0410-b5e6-96231b3b80d8
We only generate LOCKed versions of add/sub when the result is unused.
It often happens that the result is used, but only by a comparison. We
can optimize those out by reusing EFLAGS, which lets us use the proper
instructions, instead of having to fallback to LXADD.
Instead of doing this as an MI peephole (as we do for the other
non-LOCKed (really, non-MR) forms), do it in ISel. It becomes quite
tricky later.
This also makes it eventually possible to stop expanding and/or/xor
if the only user is an icmp (also see D18141).
This uses the LOCK ISD opcodes added by r262244.
Differential Revision: http://reviews.llvm.org/D17633
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265450 91177308-0d34-0410-b5e6-96231b3b80d8
destruction.
This makes the Expected<T> class behave like Error, even when in success mode.
Expected<T> values must be checked to see whether they contain an error prior
to being dereferenced, assigned to, or destructed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265446 91177308-0d34-0410-b5e6-96231b3b80d8
Also, hardcode (there must be a better way...) the 'utils' dir in the
advertisement, so it's easier to find.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265444 91177308-0d34-0410-b5e6-96231b3b80d8
At IR level, the swifterror argument is an input argument with type
ErrorObject**. For targets that support swifterror, we want to optimize it
to behave as an inout value with type ErrorObject*; it will be passed in a
fixed physical register.
The main idea is to track the virtual registers for each swifterror value. We
define swifterror values as AllocaInsts with swifterror attribute or a function
argument with swifterror attribute.
In SelectionDAGISel.cpp, we set up swifterror values (SwiftErrorVals) before
handling the basic blocks.
When iterating over all basic blocks in RPO, before actually visiting the basic
block, we call mergeIncomingSwiftErrors to merge incoming swifterror values when
there are multiple predecessors or to simply propagate them. There, we create a
virtual register for each swifterror value in the entry block. For predecessors
that are not yet visited, we create virtual registers to hold the swifterror
values at the end of the predecessor. The assignments are saved in
SwiftErrorWorklist and will be materialized at the end of visiting the basic
block.
When visiting a load from a swifterror value, we copy from the current virtual
register assignment. When visiting a store to a swifterror value, we create a
virtual register to hold the swifterror value and update SwiftErrorMap to
track the current virtual register assignment.
Differential Revision: http://reviews.llvm.org/D18108
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265433 91177308-0d34-0410-b5e6-96231b3b80d8
utils/update_test_checks.py was improved with:
http://reviews.llvm.org/rL265414
to include the first line of the function (expected to be
a comment line). This ensures that nothing bad has happened
before the first actual line of checked asm. It also matches
the existing behavior of the old script.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265416 91177308-0d34-0410-b5e6-96231b3b80d8
It was broken by reshuffling induced by r265397 'Don't delete empty preheaders in CodeGenPrepare if it would create a critical edge'.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265415 91177308-0d34-0410-b5e6-96231b3b80d8
We could make this an option if people don't like it.
But since part of the reason for using a script to generate
checks is to prevent lazy checking that lets bugs crawl
through, let's have the script check the first line too.
For asm tests, it ensures that nothing unexpected has
happened before the first line of asm. This matches the
existing behavior of update_llc_test_checks.py.
More discussion in PR22897:
https://llvm.org/bugs/show_bug.cgi?id=22897
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265414 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: LanaiSetflagAluCombiner could previously combine instructions across basic building blocks even when not legal. Make the LanaiSetflagAluCombiner more conservative to avoid this.
Reviewers: eliben
Subscribers: joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D18746
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265411 91177308-0d34-0410-b5e6-96231b3b80d8
Presently, CodeGenPrepare deletes all nearly empty (only phi and branch)
basic blocks. This pass can delete loop preheaders which frequently creates
critical edges. A preheader can be a convenient place to spill registers to
the stack. If the entrance to a loop body is a critical edge, then spills
may occur in the loop body rather than immediately before it. This patch
protects loop preheaders from deletion in CodeGenPrepare even if they are
nearly empty.
Since the patch alters the CFG, it affects a large number of test cases.
In most cases, the changes are merely cosmetic (basic blocks have different
names or instruction orders change slightly). I am somewhat concerned about
the test/CodeGen/Mips/brdelayslot.ll test case. If the loop preheader is not
deleted, then the MIPS backend does not take advantage of a branch delay
slot. Consequently, I would like some close review by a MIPS expert.
The patch also partially subsumes D16893 from George Burgess IV. George
correctly notes that CodeGenPrepare does not actually preserve the dominator
tree. I think the dominator tree was usually not valid when CodeGenPrepare
ran, but I am using LoopInfo to mark preheaders, so the dominator tree is
now always valid before CodeGenPrepare.
Author: Tom Jablin (tjablin)
Reviewers: hfinkel george.burgess.iv vkalintiris dsanders kbarton cycheng
http://reviews.llvm.org/D16984
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265397 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support for compact jumps similiar to the previous compact
branch support for MIPSR6. Unlike compact branches, compact jumps do not
have a forbidden slot.
As MipsInstrInfo::getEquivalentCompactForm can determine the correct
expansion for jumps and branches for both microMIPS and MIPSR6, remove the
unnecessary distinction in the delay slot filler.
Reviewers: vkalintiris
Subscribers: llvm-commits, dsanders
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265390 91177308-0d34-0410-b5e6-96231b3b80d8
Without setting the flag there is no way to determine if a symbol
points to an arm or to a thumb function as the LSB of the address
masked out in all getter function.
Note: Currently the thumb flag is only used for MachO files so
adding a test to this change is not possible. It will be used
by the upcoming fix for llvm-objdump for disassembling thumb
functions what is easily testable.
Differential revision: http://reviews.llvm.org/D17956
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265387 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
A character within a string literal is not escaped correctly.
In this case, there is no semantic change because the invalid character turn out to be NUL anyway.
note: "\0x12" is equivalent to {0, 'x', '1', '2'} and not { 12 }.
This issue was found by clang-tidy.
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D18747
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265376 91177308-0d34-0410-b5e6-96231b3b80d8
Refactor common code that queries the ModuleSummaryIndex for a value's
GlobalValueInfo struct into getGlobalValueInfo helper methods, which
will also be used by D18763.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265370 91177308-0d34-0410-b5e6-96231b3b80d8
Story time was nice a few years ago, but by now it's nice to state how things are, rather than explain the diff from ye olden atomic history. These were dark times.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265369 91177308-0d34-0410-b5e6-96231b3b80d8
