This reverts commit r280218. This *also* causes buildbot errors. Sigh. Not a successful day all around!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280239 91177308-0d34-0410-b5e6-96231b3b80d8
We check that a sinking candidate is used by only one PHI node during our legality checks. However for instructions that are used by other sinking candidates our heuristic is less conservative. This can result in a candidate actually being illegal when we come to sink it because of how we sunk a predecessor. Do the used-by-only-one-PHI checks again during sinking to ensure we don't crash.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280228 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Simply replace usage of aliases to functions with aliasee.
This came up when bitcode linking to builtin library and
calls to aliases not being resolved.
Also made minor improvements to existing test.
Reviewers: tstellarAMD, alex-t, vpykhtin
Subscribers: arsenm, wdng, rampitec
Differential Revision: https://reviews.llvm.org/D24023
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280221 91177308-0d34-0410-b5e6-96231b3b80d8
We're sinking stores, which is a good thing, but in the process creating selects for the store address operand, which SROA/Mem2Reg can't look through, which caused serious regressions.
The real fix is in SROA, which I'll be looking into.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280219 91177308-0d34-0410-b5e6-96231b3b80d8
A very important case is not handled here: multiple arcs to a single block with a PHI. Consider:
a:
%1 = icmp %b, 1
br %1, label %c, label %e
c:
%2 = icmp %b, 2
br %2, label %d, label %e
d:
br %e
e:
phi [0, %a], [1, %c], [2, %d]
FoldValueComparisonIntoPredecessors will refuse to fold this, as it doesn't know how to deal with two arcs to a common destination with different PHI values. The answer is obvious - just split all conflicting arcs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280218 91177308-0d34-0410-b5e6-96231b3b80d8
This was a real restriction in the original version of SinkIfThenCodeToEnd. Now it's been rewritten, the restriction can be lifted.
As part of this, we handle a very common and useful case where one of the incoming branches is actually conditional. Consider:
if (a)
x(1);
else if (b)
x(2);
This produces the following CFG:
[if]
/ \
[x(1)] [if]
| | \
| | \
| [x(2)] |
\ | /
[ end ]
[end] has two unconditional predecessor arcs and one conditional. The conditional refers to the implicit empty 'else' arc. This same pattern can also be caused by an empty default block in a switch.
We can't sink the call to x() down to end because no call to x() happens on the third incoming arc (assume that x() has sideeffects for the sake of argument; if something is safe to speculate we could indeed sink nevertheless but this cannot happen in the general case and causes many extra selects).
We are now able to detect this case and split off the unconditional arcs to a common successor:
[if]
/ \
[x(1)] [if]
| | \
| | \
| [x(2)] |
\ / |
[sink.split] |
\ /
[ end ]
Now we can sink the call to x() into %sink.split. This can cause significant code simplification in many testcases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280217 91177308-0d34-0410-b5e6-96231b3b80d8
r279460 rewrote this function to be able to handle more than two incoming edges and took pains to ensure this didn't regress anything.
This time we change the logic for determining if an instruction should be sunk. Previously we used a single pass greedy algorithm - sink instructions until one requires more than one PHI node or we run out of instructions to sink.
This had the problem that sinking instructions that had non-identical but trivially the same operands needed extra logic so we sunk them aggressively. For example:
%a = load i32* %b %d = load i32* %b
%c = gep i32* %a, i32 0 %e = gep i32* %d, i32 1
Sinking %c and %e would naively require two PHI merges as %a != %d. But the loads are obviously equivalent (and maybe can't be hoisted because there is no common predecessor).
This is why we implemented the fairly complex function areValuesTriviallySame(), to look through trivial differences like this. However it's just not clever enough.
Instead, throw areValuesTriviallySame away, use pointer equality to check equivalence of operands and switch to a two-stage algorithm.
In the "scan" stage, we look at every sinkable instruction in isolation from end of block to front. If it's sinkable, we keep track of all operands that required PHI merging.
In the "sink" stage, we iteratively sink the last non-terminator in the source blocks. But when calculating how many PHIs are actually required to be inserted (to work out if we should stop or not) we remove any values that have already been sunk from the set of PHI-merges required, which allows us to be more aggressive.
This turns an algorithm with potentially recursive lookahead (looking through GEPs, casts, loads and any other instruction potentially not CSE'd) to two linear scans.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280216 91177308-0d34-0410-b5e6-96231b3b80d8
This was deliberately disabled during my rewrite of SinkIfThenToEnd to keep behaviour
at least vaguely consistent with the previous version and keep it as close to NFC as
I could.
There's no real reason not to merge sideeffect calls though, so let's do it! Small fixup
along the way to ensure we don't create indirect calls.
Should fix PR28964.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280215 91177308-0d34-0410-b5e6-96231b3b80d8
Move the comparison function into the only place there it is used,
i.e. the call to std::stable_sort in CoverageMappingWriter::write().
Add sorting by region kinds as it is required to ensure stable order
in our tests and to simplify D23987.
Differential Revision: https://reviews.llvm.org/D24034
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280198 91177308-0d34-0410-b5e6-96231b3b80d8
Test cases taken from optimized clang output after trying to convert the masked floating point logical op intrinsics to native IR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280194 91177308-0d34-0410-b5e6-96231b3b80d8
There were paths where we wouldn't populate the visited set, causing us
to recurse forever if an SSA variable was defined in terms of itself.
This fixes PR30210.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280191 91177308-0d34-0410-b5e6-96231b3b80d8
When a function contains something, such as inline asm, which explicitly
clobbers the register used as the frame pointer, don't spill it twice. If we
need a frame pointer, it will be saved/restored in the prologue/epilogue code.
Explicitly spilling it again will reuse the same spill slot used by the
prologue/epilogue code, thus clobbering the saved value. The same applies
to the base-pointer or PIC-base register.
Partially fixes PR26856. Thanks to Ulrich for his analysis and the small
inline-asm reproducer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280188 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
1) CoroEarly now lowers llvm.coro.promise intrinsic that allows to obtain
a coroutine promise pointer from a coroutine frame and vice versa.
2) CoroFrame now interprets Promise argument of llvm.coro.begin to
place CoroutinPromise alloca at a deterministic offset from the coroutine frame.
Now, the coroutine promise example from docs\Coroutines.rst compiles and produces expected result (see test/Transform/Coroutines/ex4.ll).
Reviewers: majnemer
Subscribers: llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D23993
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280184 91177308-0d34-0410-b5e6-96231b3b80d8
It's much less code and easier to read if we don't duplicate
everything between the 'Inside' and not 'Inside' cases.
As noted with the FIXME, the goal is to make this vector-friendly
in a follow-up patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280183 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
LSV was using two vector sets (heads and tails) to track pairs of adjiacent position to vectorize.
A recent optimization is trying to obtain the longest chain to vectorize and assumes the positions
in heads(H) and tails(T) match, which is not the case is there are multiple tails for the same head.
e.g.:
i1: store a[0]
i2: store a[1]
i3: store a[1]
Leads to:
H: i1
T: i2 i3
Instead of:
H: i1 i1
T: i2 i3
So the positions for instructions that follow i3 will have different indexes in H/T.
This patch resolves PR29148.
This issue also surfaced the fact that if the chain is too long, and TLI
returns a "not-fast" answer, the whole chain will be abandoned for
vectorization, even though a smaller one would be beneficial.
Added a testcase and FIXME for this.
Reviewers: tstellarAMD, arsenm, jlebar
Subscribers: mzolotukhin, wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D24057
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280179 91177308-0d34-0410-b5e6-96231b3b80d8
As written, the code should assert if this lookup would have ever
succeeded. Without looking through composite types, the type graph
should be acyclic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280168 91177308-0d34-0410-b5e6-96231b3b80d8
Still no unit test due to synchronization bugs on s390. These issues were
discovered in an out-of-tree utility.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280163 91177308-0d34-0410-b5e6-96231b3b80d8
This will enable other runtime projects to detect the presence of sanitizer runtimes by referring to the sanitizer targets directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280162 91177308-0d34-0410-b5e6-96231b3b80d8
Legalization ends up creating many G_SEQUENCE/G_EXTRACT pairs which leads to
inefficient codegen (even for -O0), so add a quick pass over the function to
remove them again.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280155 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 8df7a877949e8782a3a28e3ecdb0770c1e444056.
Fixing other repositories and adding changes together.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280152 91177308-0d34-0410-b5e6-96231b3b80d8
When binaries are compressed by UPX, information about symbol table
offset and symbol count remain unchanged (but became invalid due to
compression).
This causes failure in the constructor and the rest of the binary cannot
be processed.
Instead, reset symbol related information (symbol/string table pointers,
sizes) - this should disable the related iterators and functions while
the rest of the binary can still be processed.
Patch by Bandzi Michal!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280147 91177308-0d34-0410-b5e6-96231b3b80d8
We're intending to move to a world where the type of a register is determined
by its (unique) def. This is incompatible with physregs, which are untyped.
It also means the other passes don't have to worry quite so much about
register-class compatibility and inserting COPYs appropriately.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280132 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for printing the GNU Notes. This allows an easy way to view the
build id for a binary built with the build id. Currently, this only handles the
GNU notes, though it would be easy to extend for other note types (default,
FreeBSD, NetBSD, etc). Only the GNU style is supported currently.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280131 91177308-0d34-0410-b5e6-96231b3b80d8
Add constants for additional GNU note types and the GNU Notes OS type id. This
is needed to support printing the notes in ELF binaries.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280130 91177308-0d34-0410-b5e6-96231b3b80d8
Many lists want to override only allocation semantics, or callbacks for
iplist. Split these up to prevent code duplication.
- Specialize ilist_alloc_traits to change the implementations of
deleteNode() and createNode().
- One common desire is to do nothing deleteNode() and disable
createNode(). Specialize ilist_alloc_traits to inherit from
ilist_noalloc_traits for that behaviour.
- Specialize ilist_callback_traits to use the addNodeToList(),
removeNodeFromList(), and transferNodesFromList() callbacks.
As a drive-by, add some coverage to the callback-related unit tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280128 91177308-0d34-0410-b5e6-96231b3b80d8