Refactored so that a LSRUse owns its fixups, as oppsed to letting the
LSRInstance own them. This makes it easier to rate formulas for
LSRUses, since the fixups are available directly. The Offsets vector
has been removed since it was no longer necessary.
New target hook isFoldableMemAccessOffset(), which is used during formula
rating.
For SystemZ, this is useful to express that loads and stores with
float or vector types with a big/negative offset should be avoided in
loops. Without this, LSR will generate a lot of negative offsets that
would require extra instructions for loading the address.
Updated tests:
test/CodeGen/SystemZ/loop-01.ll
Reviewed by: Quentin Colombet and Ulrich Weigand.
https://reviews.llvm.org/D19152
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278927 91177308-0d34-0410-b5e6-96231b3b80d8
In theory the indices of RC (and thus the index used for LiveRegs) may differ from the indices of OpRC.
Fixed the code to extract the correct RC index.
OpRC contains the first X consecutive elements of RC, and thus their indices are currently de facto the same, therefore a test cannot be added at this point.
Differential Revision: https://reviews.llvm.org/D23491
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278923 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This change fix bug in AMDGPU disassembly. Previously, presence of symbols other than kernel symbols caused objdump to skip begining of those symbols.
Reviewers: tstellarAMD, vpykhtin, Bigcheese, ruiu
Subscribers: kzhuravl, arsenm
Differential Revision: http://reviews.llvm.org/D21966
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278921 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
See D22198 for the motivation: We have a pass that uses LiveIntervals anyway,
and there is now a requirement to track a physical register that is not
usually tracked at this point of the compilation. The pass also introduces
instructions that affect this physical register, but we want to preserve
LiveIntervals.
Rather than add brittle and rarely exercised code to keep the tracking of
the physical register intact, we want to just remove the corresponding
LiveRange -- it didn't exist before anyway, and subsequent passes don't
expect it to be there.
Reviewers: MatzeB, arsenm
Subscribers: llvm-commits, MatzeB
Differential Revision: https://reviews.llvm.org/D22801
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278920 91177308-0d34-0410-b5e6-96231b3b80d8
can given the current __cplusplus definitions).
Without this, Clang triggers TONS of warnings about using a C++17
extension. I tried using LLVM_EXTENSION to turn these off and it doesn't
work.
Suggestions on a better approach are welcome, but at least this makes
the build usable for me again.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278909 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
While NFC for now, this will allow more flexibility on the client side
to hold state necessary to back up the stream.
Also when adding caching, this class will grow in complexity.
Note I blindly modified the gold-plugin as I can't compile it.
Reviewers: tejohnson
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D23542
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278907 91177308-0d34-0410-b5e6-96231b3b80d8
This is a mechanical change of comments in switches like fallthrough,
fall-through, or fall-thru to use the LLVM_FALLTHROUGH macro instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278902 91177308-0d34-0410-b5e6-96231b3b80d8
Now the tests of TargetParser is in place:
unittests/Support/TargetParserTest.cpp.
So the tests in TripleTest.cpp which actually stressing TargetParser's behavior could be removed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278899 91177308-0d34-0410-b5e6-96231b3b80d8
minimal and boring form than the old pass manager's version.
This pass does the very minimal amount of work necessary to inline
functions declared as always-inline. It doesn't support a wide array of
things that the legacy pass manager did support, but is alse ... about
20 lines of code. So it has that going for it. Notably things this
doesn't support:
- Array alloca merging
- To support the above, bottom-up inlining with careful history
tracking and call graph updates
- DCE of the functions that become dead after this inlining.
- Inlining through call instructions with the always_inline attribute.
Instead, it focuses on inlining functions with that attribute.
The first I've omitted because I'm hoping to just turn it off for the
primary pass manager. If that doesn't pan out, I can add it here but it
will be reasonably expensive to do so.
The second should really be handled by running global-dce after the
inliner. I don't want to re-implement the non-trivial logic necessary to
do comdat-correct DCE of functions. This means the -O0 pipeline will
have to be at least 'always-inline,global-dce', but that seems
reasonable to me. If others are seriously worried about this I'd like to
hear about it and understand why. Again, this is all solveable by
factoring that logic into a utility and calling it here, but I'd like to
wait to do that until there is a clear reason why the existing
pass-based factoring won't work.
The final point is a serious one. I can fairly easily add support for
this, but it seems both costly and a confusing construct for the use
case of the always inliner running at -O0. This attribute can of course
still impact the normal inliner easily (although I find that
a questionable re-use of the same attribute). I've started a discussion
to sort out what semantics we want here and based on that can figure out
if it makes sense ta have this complexity at O0 or not.
One other advantage of this design is that it should be quite a bit
faster due to checking for whether the function is a viable candidate
for inlining exactly once per function instead of doing it for each call
site.
Anyways, hopefully a reasonable starting point for this pass.
Differential Revision: https://reviews.llvm.org/D23299
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278896 91177308-0d34-0410-b5e6-96231b3b80d8
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 &).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278894 91177308-0d34-0410-b5e6-96231b3b80d8
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.htmlhttp://lists.llvm.org/pipermail/llvm-dev/2016-August/103285.html
Differential Revision: https://reviews.llvm.org/D23052
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278892 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278887 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278886 91177308-0d34-0410-b5e6-96231b3b80d8
IsOperandBundleUse conveniently indicates whether
std::next(F->arg_begin(),UseIndex) will get to (or past) end(). Check
it first to avoid dereferencing end().
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278884 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278883 91177308-0d34-0410-b5e6-96231b3b80d8
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().
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278881 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278880 91177308-0d34-0410-b5e6-96231b3b80d8
The end() iterator isn't a safe thing to dereference. Pass the DebugLoc
into EmitFetchClause and EmitALUClause to avoid it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278873 91177308-0d34-0410-b5e6-96231b3b80d8
When comparing a User* to a BasicBlock::iterator in
passingValueIsAlwaysUndefined, don't dereference the iterator in case it
is end().
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278872 91177308-0d34-0410-b5e6-96231b3b80d8
This is hitting a "use of undeclared identifier 'skipPadding' error
locally and on some bots.
This reverts r278869.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278871 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278870 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278868 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278866 91177308-0d34-0410-b5e6-96231b3b80d8
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().
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278858 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278854 91177308-0d34-0410-b5e6-96231b3b80d8
