Without this fix clang 3.6 complains with:
../lib/Target/ARM/ARMAsmPrinter.cpp:1473:18: error: variable 'BranchTarget' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
} else if (MI->getOperand(1).isSymbol()) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
../lib/Target/ARM/ARMAsmPrinter.cpp:1479:22: note: uninitialized use occurs here
MCInst.addExpr(BranchTarget);
^~~~~~~~~~~~
../lib/Target/ARM/ARMAsmPrinter.cpp:1473:14: note: remove the 'if' if its condition is always true
} else if (MI->getOperand(1).isSymbol()) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../lib/Target/ARM/ARMAsmPrinter.cpp:1465:33: note: initialize the variable 'BranchTarget' to silence this warning
const MCExpr *BranchTarget;
^
= nullptr
1 error generated.
Discussed here:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190610/661417.html
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363166 91177308-0d34-0410-b5e6-96231b3b80d8
This changes the standalone pass only. Arguably the utility class
itself should assert there are no convergent calls. However, a target
pass with additional context may still be able to version a loop if
all of the dynamic conditions are sufficiently uniform.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363165 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Fix hoisting to basic block which are not legal for hoisting cause
it can be terminated by exception or it is return block.
Reviewers: john.brawn, RKSimon, MatzeB
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63148
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363164 91177308-0d34-0410-b5e6-96231b3b80d8
r362951 was supposed to contain this test, however it didn't get committed
due to operator error. This was originally part of D59431.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363161 91177308-0d34-0410-b5e6-96231b3b80d8
This case is slightly tricky, because loop distribution should be
allowed in some cases, and not others. As long as runtime dependency
checks don't need to be introduced, this should be OK. This is further
complicated by the fact that LoopDistribute partially ignores if LAA
says that vectorization is safe, and then does its own runtime pointer
legality checks.
Note this pass still does not handle noduplicate correctly, as this
should always be forbidden with it. I'm not going to bother trying to
fix it, as it would require more effort and I think noduplicate should
be removed.
https://reviews.llvm.org/D62607
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363160 91177308-0d34-0410-b5e6-96231b3b80d8
Implement the backend target hook to drive the HardwareLoops pass.
The low-overhead branch extension for Arm M-class cores is flexible
enough that we don't have to ensure correctness at this point, except
checking that the loop counter variable can be stored in LR - a
32-bit register. For it to be profitable, we want to avoid loops that
contain function calls, or any other instruction that alters the PC.
This implementation uses TargetLoweringInfo, to query type and
operation actions, looks at intrinsic calls and also performs some
manual checks for remainder/division and FP operations.
I think this should be a good base to start and extra details can be
filled out later.
Differential Revision: https://reviews.llvm.org/D62907
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363149 91177308-0d34-0410-b5e6-96231b3b80d8
'Use wrap flags in InsertBinop' (rL362687) was reverted due to
miscompiles. This patch introduces the previous change to pass
no-wrap flags but now only FlagAnyWrap is passed.
Differential Revision: https://reviews.llvm.org/D61934
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363147 91177308-0d34-0410-b5e6-96231b3b80d8
r363016 let lld-link and llvm-lib share the /machine: parsing code.
This lets llvm-cvtres share it as well.
Making llvm-cvtres depend on llvm-lib seemed a bit strange (it doesn't
need llvm-lib's dependencies on BinaryFormat and BitReader) and I
couldn't find a good place to put this code. Since it's just a few
lines, put it in lib/Object for now.
Differential Revision: https://reviews.llvm.org/D63120
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363144 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: In this patch, I updated `load` instruction syntax and fixed function definition. Besides, I re-named some variables to make them obey SSA rule.
Reviewers: MaskRay
Reviewed By: MaskRay
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63186
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363142 91177308-0d34-0410-b5e6-96231b3b80d8
Noticed in D63075 - there was a allowsMisalignedMemoryAccesses call to check for unaligned loads and a check for aligned legal type loads - which is exactly what allowsMemoryAccess does.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363141 91177308-0d34-0410-b5e6-96231b3b80d8
Dependent libraries support for the legacy api was committed in a
broken state (see: https://reviews.llvm.org/D60274). This was missed
due to the painful nature of having to integrate the changes into a
linker in order to test. This change implements support for dependent
libraries in the legacy LTO api:
- I have removed the current api function, which returns a single
string, and added functions to access each dependent library
specifier individually.
- To reduce the testing pain, I have made the api functions as thin as
possible to maximize coverage from llvm-lto.
- When doing ThinLTO the system linker will load the modules lazily
when scanning the input files. Unfortunately, when modules are
lazily loaded there is no access to module level named metadata. To
fix this I have added api functions that allow querying the IRSymtab
for the dependent libraries. I hope to expand the api in the future
so that, eventually, all the information needed by a client linker
during scan can be retrieved from the IRSymtab.
Differential Revision: https://reviews.llvm.org/D62935
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363140 91177308-0d34-0410-b5e6-96231b3b80d8
Noticed in D63075 - there was a allowsMisalignedMemoryAccesses call to check for unaligned loads and a check for aligned legal type loads - which is exactly what allowsMemoryAccess does.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363137 91177308-0d34-0410-b5e6-96231b3b80d8
The --print-size help text and documentation claimed that the size was
printed instead of the address, but this is incorrect. It is printed as
well as the address. This patch fixes this issue.
Reviewed by: MaskRay, mtrent, ruiu
Differential Revision: https://reviews.llvm.org/D63142
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363136 91177308-0d34-0410-b5e6-96231b3b80d8
When these tests were originally written, the middle end would introduce
an unnecessary copy from r24:r23->GPR16->r24:r23, and these tests
mistakenly relied on it.
The most optimal codegen for the functions in the test cases before this patch
would be NOPs. This is because the first i16 argument always gets the same register
allocation as an i16 return value in the AVR calling convention.
These tests broke in r362963 when the codegen was improved and the
redundant copy was eliminated. After this, the test functions
were lowered to their optimal form - a 'ret' and nothing else.
This patch prepends an extra i16 operand to each of the test functions
so that a 16-bit copy must be inserted for the program to be correct.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363131 91177308-0d34-0410-b5e6-96231b3b80d8
Extern global merging is good for code-size. There's definitely potential for
performance too, but there's one regression in a benchmark that needs
investigating, so that's why we enable it only when we optimise for size for
now.
Patch by Ramakota Reddy and Sjoerd Meijer.
Differential Revision: https://reviews.llvm.org/D61947
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363130 91177308-0d34-0410-b5e6-96231b3b80d8
The non-masked versions are already in there. I'm having some
trouble coming up with a way to test this right now. Most load
folding should happen during isel so I'm not sure how to get
peephole pass to do it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363125 91177308-0d34-0410-b5e6-96231b3b80d8
The issue is that if we have a loop with multiple predecessors outside the loop, the code was expecting to merge them and only return if equal, but instead returned the first one seen.
I have no idea if this actually tripped anywhere. I noticed it by accident when reading the code and have no idea how to go about constructing a test case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363112 91177308-0d34-0410-b5e6-96231b3b80d8
We were only matching RHS being a loop invariant value, not the inverse. Since there's nothing which appears to canonicalize loop invariant values to RHS, this means we missed cases.
Differential Revision: https://reviews.llvm.org/D63112
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363108 91177308-0d34-0410-b5e6-96231b3b80d8
Looks like a MachinePipeliner algorithm problem found by
sanitizer-x86_64-linux-fast.
I will backout this test first while investigating the problem to
unblock buildbot.
==49637==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x614000002e08 at pc 0x000004364350 bp 0x7ffe228a3bd0 sp 0x7ffe228a3bc8
READ of size 4 at 0x614000002e08 thread T0
#0 0x436434f in
llvm::SwingSchedulerDAG::checkValidNodeOrder(llvm::SmallVector<llvm::NodeSet,
8u> const&) const
/b/sanitizer-x86_64-linux-fast/build/llvm/lib/CodeGen/MachinePipeliner.cpp:3736:11
#1 0x4342cd0 in llvm::SwingSchedulerDAG::schedule()
/b/sanitizer-x86_64-linux-fast/build/llvm/lib/CodeGen/MachinePipeliner.cpp:486:3
#2 0x434042d in
llvm::MachinePipeliner::swingModuloScheduler(llvm::MachineLoop&)
/b/sanitizer-x86_64-linux-fast/build/llvm/lib/CodeGen/MachinePipeliner.cpp:385:7
#3 0x433eb90 in
llvm::MachinePipeliner::runOnMachineFunction(llvm::MachineFunction&)
/b/sanitizer-x86_64-linux-fast/build/llvm/lib/CodeGen/MachinePipeliner.cpp:207:5
#4 0x428b7ea in
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
/b/sanitizer-x86_64-linux-fast/build/llvm/lib/CodeGen/MachineFunctionPass.cpp:73:13
#5 0x4d1a913 in llvm::FPPassManager::runOnFunction(llvm::Function&)
/b/sanitizer-x86_64-linux-fast/build/llvm/lib/IR/LegacyPassManager.cpp:1648:27
#6 0x4d1b192 in llvm::FPPassManager::runOnModule(llvm::Module&)
/b/sanitizer-x86_64-linux-fast/build/llvm/lib/IR/LegacyPassManager.cpp:1685:16
#7 0x4d1c06d in runOnModule
/b/sanitizer-x86_64-linux-fast/build/llvm/lib/IR/LegacyPassManager.cpp:1752:27
#8 0x4d1c06d in llvm::legacy::PassManagerImpl::run(llvm::Module&)
/b/sanitizer-x86_64-linux-fast/build/llvm/lib/IR/LegacyPassManager.cpp:1865
#9 0xa48ca3 in compileModule(char**, llvm::LLVMContext&)
/b/sanitizer-x86_64-linux-fast/build/llvm/tools/llc/llc.cpp:611:8
#10 0xa4270f in main
/b/sanitizer-x86_64-linux-fast/build/llvm/tools/llc/llc.cpp:365:22
#11 0x7fec902572e0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
#12 0x971b69 in _start
(/b/sanitizer-x86_64-linux-fast/build/llvm_build_asan/bin/llc+0x971b69)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363105 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This splits out a section in the command guide for llvm tools that can be used as replacements for GNU tools. For pages that didn't exist, I added stub pages that can be individually filled in by followup patches.
Tested by running `ninja docs-llvm-html` and inspecting locally.
Reviewers: jhenderson, MaskRay, grimar, alexshap
Reviewed By: jhenderson, MaskRay, grimar
Subscribers: smeenai, arphaman, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63014
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363100 91177308-0d34-0410-b5e6-96231b3b80d8
This opcode generates a pointer to the address of the jump table
specified by the source operand, which is a jump table index.
It will be used in conjunction with an upcoming G_BRJT opcode to support
jump table codegen with GlobalISel.
Differential Revision: https://reviews.llvm.org/D63111
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363096 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: After applying a set of insert updates, there may be trivial Phis left over. Clean them up.
Reviewers: george.burgess.iv
Subscribers: jlebar, Prazek, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63033
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363094 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The method `getLoopPassPreservedAnalyses` should not mark MemorySSA as
preserved, because it's being called in a lot of passes that do not
preserve MemorySSA.
Instead, mark the MemorySSA analysis as preserved by each pass that does
preserve it.
These changes only affect the new pass mananger.
Reviewers: chandlerc
Subscribers: mehdi_amini, jlebar, Prazek, george.burgess.iv, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62536
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363091 91177308-0d34-0410-b5e6-96231b3b80d8
