| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
| |
Also avoid some pointless use of auto! Because that's friendlier to
readers and avoids several types accidentally resolving to unnecessary
references here (MachineInstr *&, unsigned &).
llvm-svn: 278894
|
| |
|
|
| |
llvm-svn: 278893
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is off for now while testing can take place to make sure that in
fact we do sufficient stack coloring to fully obviate the manual alloca
array merging.
Some context on why we should be using stack coloring rather than
merging allocas in this way:
LLVM relies very heavily on analyzing pointers as coming from different
allocas in order to make aliasing decisions. These are some of the most
powerful aliasing signals available in LLVM. So merging allocas is an
extremely destructive operation on the LLVM IR -- it takes away highly
valuable and hard to reconstruct information.
As a consequence, inlined functions which happen to have array allocas
that this pattern matches will fail to be properly interleaved unless
SROA manages to hoist everything to an SSA register. Instead, the
inliner will have added an unnecessary dependence that one inlined
function execute after the other because they will have been rewritten
to refer to the same memory.
All that said, folks will reasonably want some time to experiment here
and make sure there are no significant regressions. A flag should give
us an easy knob to test.
For more context, see the thread here:
http://lists.llvm.org/pipermail/llvm-dev/2016-July/103277.html
http://lists.llvm.org/pipermail/llvm-dev/2016-August/103285.html
Differential Revision: https://reviews.llvm.org/D23052
llvm-svn: 278892
|
| |
|
|
| |
llvm-svn: 278888
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These splices are interesting because they involve swapping two nodes in
the same list. There are two ways to do this. Assuming:
A -> B -> [Sentinel]
You can either:
- splice B before A, with: L.splice(A, L, B) or
- splice A before Sentinel, with: L.splice(L.end(), L, A) to create:
B -> A -> [Sentinel]
These two swapping-splices are somewhat interesting corner cases for
maintaining the list invariants. The tests pass even with my new ilist
implementation, but I had some doubts about the latter when I was
looking at weird UB effects. Since I can't find equivalent explicit
test coverage elsewhere it seems prudent to commit.
llvm-svn: 278887
|
| |
|
|
|
|
|
|
|
| |
IndVarSimplify::sinkUnusedInvariants calls
BasicBlock::getFirstInsertionPt on the ExitBlock and moves instructions
before it. This can return end(), so it's not safe to dereference. Add
an iterator-based overload to Instruction::moveBefore to avoid the UB.
llvm-svn: 278886
|
| |
|
|
|
|
| |
Thanks to Sean Silva for bringing these up. :)
llvm-svn: 278885
|
| |
|
|
|
|
|
|
| |
IsOperandBundleUse conveniently indicates whether
std::next(F->arg_begin(),UseIndex) will get to (or past) end(). Check
it first to avoid dereferencing end().
llvm-svn: 278884
|
| |
|
|
|
|
|
|
|
| |
BasicBlock::Create isn't designed to take iterators (which might be
end()), but pointers (which might be nullptr). Fix the UB that was
converting end() to a BasicBlock* by calling BasicBlock::getNextNode()
in the first place.
llvm-svn: 278883
|
| |
|
|
|
|
|
|
|
| |
When there's only one argument and it doesn't match one of the known
functions, return ARCInstKind::CallOrUser rather than falling through
to the two argument case. The old behaviour both incremented past and
dereferenced end().
llvm-svn: 278881
|
| |
|
|
|
|
|
|
| |
llvm::tryFoldSPUpdateIntoPushPop assumes its arguments are valid
MachineInstrs. Update ARMFrameLowering::emitPrologue to respect that;
when LastPush==end(), it can't possibly be a push instruction anyway.
llvm-svn: 278880
|
| |
|
|
| |
llvm-svn: 278879
|
| |
|
|
| |
llvm-svn: 278878
|
| |
|
|
|
|
|
|
| |
Patch partially by Danny.
Differential Revision: https://reviews.llvm.org/D23535
llvm-svn: 278875
|
| |
|
|
|
|
|
| |
The end() iterator isn't a safe thing to dereference. Pass the DebugLoc
into EmitFetchClause and EmitALUClause to avoid it.
llvm-svn: 278873
|
| |
|
|
|
|
|
|
| |
When comparing a User* to a BasicBlock::iterator in
passingValueIsAlwaysUndefined, don't dereference the iterator in case it
is end().
llvm-svn: 278872
|
| |
|
|
|
|
|
|
|
| |
This is hitting a "use of undeclared identifier 'skipPadding' error
locally and on some bots.
This reverts r278869.
llvm-svn: 278871
|
| |
|
|
|
|
|
|
| |
Rather than doing a funny dance that relies on dereferencing end() not
crashing, add some API to MachineInstrBundleIterator to get a non-const
version of the iterator.
llvm-svn: 278870
|
| |
|
|
|
|
|
| |
Reviewed By: ruiu, rnk
Differential Revision: https://reviews.llvm.org/D23226
llvm-svn: 278869
|
| |
|
|
|
|
|
|
| |
This allows you to annotate switch case fallthrough in a better way
than a "// FALLTHROUGH" comment. Eventually it would be nice to turn
on -Wimplicit-fallthrough, if we can get the code base clean.
llvm-svn: 278868
|
| |
|
|
| |
llvm-svn: 278867
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If AnalyzeBranch can't analyze a block and it is possible to
fallthrough, then duplicating the block doesn't make sense, as only one
block can be the layout predecessor for the un-analyzable fallthrough.
Submitted wit a test case, but NOTE: the test case doesn't currently
fail. However, the test case fails with D20505 and would have saved me
some time debugging.
llvm-svn: 278866
|
| |
|
|
|
|
|
|
|
|
|
| |
1. Fix variable names
2. Add local variables to reduce code
3. Fix code comments
4. Add early exit to reduce indentation
5. Remove 'else' after if -> return
6. Hoist common predicate
llvm-svn: 278864
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D23556
llvm-svn: 278863
|
| |
|
|
|
|
|
| |
We were clearing it out in LoopUnswitch and InlineFunction instead of
attempting to preserve it.
llvm-svn: 278860
|
| |
|
|
|
|
| |
constant vectors
llvm-svn: 278859
|
| |
|
|
|
|
|
|
| |
The current MachineBasicBlock might be the last block, so FallThru may
be past the end(). Use getNextNode(), which will convert to nullptr,
rather than &*++, which is invalid if we reach the end().
llvm-svn: 278858
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
for code size savings, for 64-bit constants.
This patch handles 64-bit constants which can be encoded as 32-bit immediates.
It extends the functionality added by https://reviews.llvm.org/D11363 for 32-bit constants to 64-bit constants.
Patch by Sunita Marathe!
Differential Revision: https://reviews.llvm.org/D23391
llvm-svn: 278857
|
| |
|
|
| |
llvm-svn: 278856
|
| |
|
|
| |
llvm-svn: 278855
|
| |
|
|
|
|
|
|
|
|
|
| |
Clearing out the AssumptionCache can cause us to rescan the entire
function for assumes. If there are many loops, then we are scanning
over the entire function many times.
Instead of clearing out the AssumptionCache, register all cloned
assumes.
llvm-svn: 278854
|
| |
|
|
|
|
|
|
| |
stride."
This reverts commit r278731. It caused http://crbug.com/638314
llvm-svn: 278853
|
| |
|
|
| |
llvm-svn: 278847
|
| |
|
|
|
|
| |
Refine the model for the FP division unit.
llvm-svn: 278846
|
| |
|
|
|
|
| |
Refine the model for the integer division unit.
llvm-svn: 278845
|
| |
|
|
|
|
|
|
|
|
|
| |
The structs ImmOp and RegOp are in AArch64AsmParser.cpp (inside
anonymous namespace).
This diff changes the order of fields and removes the excessive padding
(8 bytes).
Patch by Alexander Shaposhnikov
llvm-svn: 278844
|
| |
|
|
| |
llvm-svn: 278843
|
| |
|
|
|
|
| |
Rename the operands to make the test less brittle.
llvm-svn: 278841
|
| |
|
|
|
|
|
|
|
|
| |
Do not reorder and move up a loop latch block before a loop header
when optimising for size because this will generate an extra
unconditional branch.
Differential Revision: https://reviews.llvm.org/D22521
llvm-svn: 278840
|
| |
|
|
|
|
| |
affect control flow and treats new values as new coverage.
llvm-svn: 278839
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The struct LineNoCacheTy is in SourceMgr.cpp inside anonymous namespace.
This diff changes the order of fields and removes the excessive padding
(8 bytes).
Patch by Alexander Shaposhnikov!
Differential revision: https://reviews.llvm.org/D23546
llvm-svn: 278838
|
| |
|
|
|
|
|
|
| |
It is pretty easy to get it down to O(nlogn + mlogm). This
implementation has the added benefit of automatically deduplicating
entries between the two sets.
llvm-svn: 278837
|
| |
|
|
|
|
|
|
|
|
|
| |
I have audited all the callers of concatenate and none require duplicate
entries to service concatenation.
These duplicates serve no purpose but to needlessly embiggen the IR.
N.B. Layering getMostGenericAliasScope on top of concatenate makes it
O(nlogn + mlogm) instead of O(n*m).
llvm-svn: 278836
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
ALIGNA PS_aligna
ALLOCA PS_alloca
TFR_FI PS_fi
TFR_FIA PS_fia
TFR_PdFalse PS_false
TFR_PdTrue PS_true
VMULW PS_vmulw
VMULW_ACC PS_vmulw_acc
llvm-svn: 278832
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch adds simple coroutine splitting logic to CoroSplit pass.
Documentation and overview is here: http://llvm.org/docs/Coroutines.html.
Upstreaming sequence (rough plan)
1.Add documentation. (https://reviews.llvm.org/D22603)
2.Add coroutine intrinsics. (https://reviews.llvm.org/D22659)
...
7. Split coroutine into subfunctions <= we are here
8. Coroutine Frame Building algorithm
9. Handle coroutine with unwinds
10+. The rest of the logic
Reviewers: majnemer
Subscribers: llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D23461
llvm-svn: 278830
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Besides breaking up a 700 line function to improve readability,
this sinks the 'FIXME: ConstantInt' check into each helper. So
now we can independently break that restriction within any of the
helper functions.
As much as possible, the code was only {cut/paste/clang-format}'ed
to minimize risk (no functional changes intended), so several more
readability improvements are still possible.
llvm-svn: 278828
|
| |
|
|
| |
llvm-svn: 278825
|
| |
|
|
|
|
|
|
|
|
|
| |
Check both operands for use of the $zero register which cannot be used with
a compact branch instruction.
Reviewers: dsanders, vkalintris
Differential Review: https://reviews.llvm.org/D23547
llvm-svn: 278824
|
| |
|
|
| |
llvm-svn: 278823
|
| |
|
|
|
|
|
|
|
|
|
|
| |
location from the instruction
that immediately follows the rematerialization point.
Patch by Andrea DiBiagio.
Differential Revision: http://reviews.llvm.org/D23539
llvm-svn: 278822
|