We have observed some failures with internal builds with this revision.
- Performance regressions:
- llvm's SingleSource/Misc evalloop shows performance regressions (although these may be red herrings).
- Benchmarks for Abseil's SwissTable.
- Correctness:
- Failures for particular libicu tests when building the Google AppEngine SDK (for PHP).
hwennborg has already been notified, and is aware of reproducer failures.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363220 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is useful for scenarios where Prologue was directly used and DWARF
5 awareness is required. The current alternative would be to either
duplicate the logic in getFileNameEntry, or to use getFileNameByIndex.
The latter isn't quite an in-place replacement - it performs some
processing, and it produces a string instead of a StringRef, meaning
the caller needs to handle its lifetime.
Reviewers: tamur, dblaikie, JDevlieghere
Reviewed By: tamur, JDevlieghere
Subscribers: aprantl, llvm-commits
Tags: #llvm, #debug-info
Differential Revision: https://reviews.llvm.org/D63228
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363210 91177308-0d34-0410-b5e6-96231b3b80d8
Filter out irrelevant options
New output:
OVERVIEW: llvm extractor
USAGE: llvm-extract [options] <input bitcode file>
OPTIONS:
Generic Options:
--help - Display available options (--help-hidden for more)
--help-list - Display list of available options (--help-list-hidden for more)
--version - Display the version of this program
llvm-extract Options:
--alias=<alias> - Specify alias to extract
--bb=<function:bb> - Specify <function, basic block> pairs to extract
--delete - Delete specified Globals from Module
-f - Enable binary output on terminals
--func=<function> - Specify function to extract
--glob=<global> - Specify global to extract
-o=<filename> - Specify output filename
--ralias=<ralias> - Specify alias(es) to extract using a regular expression
--recursive - Recursively extract all called functions
--rfunc=<rfunction> - Specify function(s) to extract using a regular expression
--rglob=<rglobal> - Specify global(s) to extract using a regular expression
Differential Revision: https://reviews.llvm.org/D62511
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363201 91177308-0d34-0410-b5e6-96231b3b80d8
The issue addressed in r363180 is more broadly relevant. For the moment, we don't actually get any of these cases because we a) restrict SCEV formation due to SCEExpander needing to preserve LCSSA, and b) don't iterate between loops.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363192 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: thin-archive.test assumes the Output/<testname> structure that lit creates. Rewrite the test in a way that still tests the same thing (creating via relative path and adding via absolute path) but doesn't assume this specific lit structure, making it possible to run in a lit emulator.
Reviewers: gbreynoo
Reviewed By: gbreynoo
Subscribers: llvm-commits, bkramer
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62930
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363189 91177308-0d34-0410-b5e6-96231b3b80d8
SCEV does not propagate arguments through one-input Phis so as to make it easy for the SCEV expander (and related code) to preserve LCSSA. It's not entirely clear this restriction is neccessary, but for the moment it exists. For this reason, we don't analyze single-entry phi inputs. However it is possible that when an this input leaves the loop through LCSSA Phi, it is a provable constant. Missing that results in an order of optimization issue in loop exit value rewriting where we miss some oppurtunities based on order in which we visit sibling loops.
This patch teaches computeSCEVAtScope about this case. We can generalize it later, but so far we can only replace LCSSA Phis with their constant loop-exiting values. We should probably also add similiar logic directly in the SCEV construction path itself.
Patch by: mkazantsev (with revised commit message by me)
Differential Revision: https://reviews.llvm.org/D58113
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363180 91177308-0d34-0410-b5e6-96231b3b80d8
As discussed on D62910, we need to check whether particular types of memory access are allowed, not just their alignment/address-space.
This NFC patch adds a MachineMemOperand::Flags argument to allowsMemoryAccess and allowsMisalignedMemoryAccesses, and wires up calls to pass the relevant flags to them.
If people are happy with this approach I can then update X86TargetLowering::allowsMisalignedMemoryAccesses to handle misaligned NT load/stores.
Differential Revision: https://reviews.llvm.org/D63075
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363179 91177308-0d34-0410-b5e6-96231b3b80d8
Handles PSHUFD/PSHUFLW/PSHUFHW (AVX2) + VPERMILPS (AVX1).
An extra AVX1 PSHUFD->VPERMILPS combine will be added in a future commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363178 91177308-0d34-0410-b5e6-96231b3b80d8
This was using its own, outdated list of possible captures. This was
at minimum not catching cmpxchg and addrspacecast captures.
One change is now any volatile access is treated as capturing. The
test coverage for this pass is quite inadequate, but this required
removing volatile in the lifetime capture test.
Also fixes some infrastructure issues to allow running just the IR
pass.
Fixes bug 42238.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363169 91177308-0d34-0410-b5e6-96231b3b80d8
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
