through PHI nodes across iterations.
This patch teaches the new advanced loop unrolling heuristics to propagate
constants into the loop from the preheader and around the backedge after
simulating each iteration. This lets us brute force solve simple recurrances
that aren't modeled effectively by SCEV. It also makes it more clear why we
need to process the loop in-order rather than bottom-up which might otherwise
make much more sense (for example, for DCE).
This came out of an attempt I'm making to develop a principled way to account
for dead code in the unroll estimation. When I implemented
a forward-propagating version of that it produced incorrect results due to
failing to propagate *cost* between loop iterations through the PHI nodes, and
it occured to me we really should at least propagate simplifications across
those edges, and it is quite easy thanks to the loop being in canonical and
LCSSA form.
Differential Revision: http://reviews.llvm.org/D11706
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243900 91177308-0d34-0410-b5e6-96231b3b80d8
While checking for the existence of the clang-tools-extra directory,
the script was not checking for its destination name, "extra", and
the script was failing when re-running without checking out new
sources.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243898 91177308-0d34-0410-b5e6-96231b3b80d8
Some functions return concrete ByteStreamers by value - explicitly
support that in the base class. (dtor can be virtual, no one seems to be
polymorphically owning/destroying them)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243897 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r243888, recommitting r243824.
This broke the Windows build due to a difference in the C++ standard
library implementation. Using emplace/forward_as_tuple should ensure
there's no need to copy ValIDs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243896 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a bug found while working on the bitcode reader. In
particular, the method BitstreamReader::AtEndOfStream doesn't always
behave correctly when processing a data streamer. The method
fillCurWord doesn't properly set CurWord/BitsInCurWord if the data
streamer was already at eof, but GetBytes had not yet set the
ObjectSize field of the streaming memory object.
This patch fixes this problem, and provides a test to show that
this problem has been fixed.
Patch by Karl Schimpf.
Differential Revision: http://reviews.llvm.org/D11391
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243890 91177308-0d34-0410-b5e6-96231b3b80d8
Since r241097, `DIBuilder` has only created distinct `DICompileUnit`s.
The backend is liable to start relying on that (if it hasn't already),
so make uniquable `DICompileUnit`s illegal and automatically upgrade old
bitcode. This is a nice cleanup, since we can remove an unnecessary
`DenseSet` (and the associated uniquing info) from `LLVMContextImpl`.
Almost all the testcases were updated with this script:
git grep -e '= !DICompileUnit' -l -- test |
grep -v test/Bitcode |
xargs sed -i '' -e 's,= !DICompileUnit,= distinct !DICompileUnit,'
I imagine something similar should work for out-of-tree testcases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243885 91177308-0d34-0410-b5e6-96231b3b80d8
This is necessary for WatchOS support, where the compact unwind format assumes
this kind of layout. For now we only want this on Swift-like CPUs though, where
it's been the Xcode behaviour for ages. Also, since it can expand the prologue
we don't want it at -Oz.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243884 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of cloning distinct `MDNode`s when linking in a module, just
move them over. The module linker destroys the source module, so the
old node would otherwise just be leaked on the context. Create the new
node in place. This also reduces the number of cloned uniqued nodes
(since it's less likely their operands have changed).
This mapping strategy is only correct when we're discarding the source,
so the linker turns it on via a ValueMapper flag, `RF_MoveDistinctMDs`.
There's nothing observable in terms of `llvm-link` output here: the
linked module should be semantically identical.
I'll be adding more 'distinct' nodes to the debug info metadata graph in
order to break uniquing cycles, so the benefits of this will partly come
in future commits. However, we should get some gains immediately, since
we have a fair number of 'distinct' `DILocation`s being linked in.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243883 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of always showing/printing all functions, a class derived from
the DOTViewer class can overwrite the set of functions that will be
processed.
This will be used (and tested) by Polly's scop viewers, but other users
can be imagined as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243881 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is useful for PNaCl's `RewriteAtomics` pass. NaCl intrinsics don't exist for some of the more exotic RMW instructions, so by refactoring this function into its own, `RewriteAtomics` can share code rewriting those atomics with `AtomicExpand` while additionally saving a few cycles by generating the `cmpxchg` NaCl-specific intrinsic with the callback. Without this patch, `RewriteAtomics` would require two extra passes over functions, by first requiring use of the full `AtomicExpand` pass to just expand the leftover exotic RMWs and then running itself again to expand resulting `cmpxchg`s.
NFC
Reviewers: jfb
Subscribers: jfb, llvm-commits
Differential Revision: http://reviews.llvm.org/D11422
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243880 91177308-0d34-0410-b5e6-96231b3b80d8
* generate function with string attribute using API,
* dump it in LL format,
* try to parse.
Add parser support for string attributes to fix the issue.
Reviewed By: reames, hfinkel
Differential Revision: http://reviews.llvm.org/D11058
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243877 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Modify the cost calculation function for interleaved accesses
to use the target-specific costs for insert/extract element and
memory operations.
This better models the case where the backend can't match
the interleaved group, and we are forced to use a wide load
and shuffle vectors.
Interleaved accesses are not enabled by default, so this shouldn't
cause a performance change.
Reviewers: jmolloy
Subscribers: jmolloy, llvm-commits
Differential Revision: http://reviews.llvm.org/D11718
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243875 91177308-0d34-0410-b5e6-96231b3b80d8
Enabling merging of extern globals appears to be generally either beneficial or
harmless. On some benchmarks suites (on Cortex-M4F, Cortex-A9, and Cortex-A57)
it gives improvements in the 1-5% range, but in the rest the overall effect is
zero.
Differential Revision: http://reviews.llvm.org/D10966
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243874 91177308-0d34-0410-b5e6-96231b3b80d8
Adjust the GlobalMergeOnExternal option so that the default behaviour is to
do whatever the Target thinks is best. Explicitly enabled or disabling the
option will override this default.
Differential Revision: http://reviews.llvm.org/D10965
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243873 91177308-0d34-0410-b5e6-96231b3b80d8
The test/DebugInfo/dwarfdump-macho-universal.test test added in r243862 uses
an input from another test's directory (test/tools/dsymutil/Inputs/fat-test.o)
which breaks our test setup.
Copying the required test input to the test's Input directory to fix the issue.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243872 91177308-0d34-0410-b5e6-96231b3b80d8
In http://reviews.llvm.org/rL215382, IT forming was made more conservative under
the belief that a flag-setting instruction was unpredictable inside an IT block on ARMv6M.
But actually, ARMv6M doesn't even support IT blocks so that's impossible. In the ARMARM for
v7M, v7AR and v8AR it states that the semantics of such an instruction changes inside an
IT block - it doesn't set the flags. So actually it is fine to use one inside an IT block
as long as the flags register is dead afterwards.
This gives significant performance improvements in a variety of MPEG based workloads.
Differential revision: http://reviews.llvm.org/D11680
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243869 91177308-0d34-0410-b5e6-96231b3b80d8
This is a minor optimization to only check for unresolved operands
inside `mapDistinctNode()` if the operands have actually changed. This
shouldn't really cause any change in behaviour. I didn't actually see a
slowdown in a profile, I was just poking around nearby and saw the
opportunity.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243866 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This currently sets the shift amount RHS to the same type as the LHS, and assumes that the LHS is a simple type. This isn't currently the case e.g. with weird integers sizes, but will eventually be true and will assert if not. That's what you get for having an experimental backend: break it and you get to keep both pieces. Most backends either set the RHS to MVT::i32 or MVT::i64, but WebAssembly is a virtual ISA and tries to have regular-looking binary operations where both operands are the same type (even if a 64-bit RHS shifter is slightly silly, hey it's free!).
Subscribers: llvm-commits, sunfish, jfb
Differential Revision: http://reviews.llvm.org/D11715
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243860 91177308-0d34-0410-b5e6-96231b3b80d8
Change `DIELoc` and `DIEBlock` to stop inheriting from `DIE`, instead
inheriting from `DIEValueList` to share the value storage API. This
awkward bit of code-sharing was also fairly confusing: neither `DIELoc`
nor `DIEBlock` represents a `DIE`, so why would they inherit from it?
Aside from the API cleanup, this should improve debug info memory usage
in the backend, since it shaves five pointers off of every `DIELoc` and
`DIEBlock`. I haven't bothered to measure the savings, though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243858 91177308-0d34-0410-b5e6-96231b3b80d8
Use `DIEValueList` as a pointer to either `DIEBlock` or `DIELoc` instead
of `DIE`, since soon they won't inherit from the latter.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243857 91177308-0d34-0410-b5e6-96231b3b80d8
Split out a helper `printValues()` for printing `DIEBlock` and `DIELoc`,
instead of relying on `DIE::print()`. The shared code was actually
fairly small there. No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243856 91177308-0d34-0410-b5e6-96231b3b80d8
Take `DIEValueList` instead of `DIE` so that `DIEBlock` and `DIELoc` can
stop inheriting from `DIE` in a future commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243855 91177308-0d34-0410-b5e6-96231b3b80d8
Rewrite `DIEValueList` as a subclass of `DIE`, renaming its API to match
`DIE`'s. This is preparation for changing `DIEBlock` and `DIELoc` to
stop inheriting from `DIE` and inherit directly from `DIEValueList`.
I thought about leaving this as a has-a relationship (and changing
`DIELoc` and `DIEBlock` to also have-a `DIEValueList`), but that seemed
to require a fair bit more boilerplate and I think it needed more
changes to the `DwarfUnit` API than this will.
No functionality change intended here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243854 91177308-0d34-0410-b5e6-96231b3b80d8
The XformToShuffleWithZero method currently checks AND masks at the per-lane level for all-one and all-zero constants and attempts to convert them to legal shuffle clear masks.
This patch generalises XformToShuffleWithZero, splitting and checking the sub-lanes of the constants down to the byte level to see if any legal shuffle clear masks are possible. This allows a lot of masks (often from legalization or truncation) to be folded into existing shuffle patterns and removes a lot of constant mask loading.
There are a few examples of poor shuffle lowering that are exposed by this patch that will be cleaned up in future patches (e.g. merging shuffles that are separated by bitcasts, x86 legalized v8i8 zero extension uses PMOVZX+AND+AND instead of AND+PMOVZX, etc.)
Differential Revision: http://reviews.llvm.org/D11518
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243831 91177308-0d34-0410-b5e6-96231b3b80d8
