| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
Given that we almost always want to handle it as DefinedRegular, just
use DefinedRegular.
llvm-svn: 280226
|
|
|
|
| |
llvm-svn: 280225
|
|
|
|
| |
llvm-svn: 280224
|
|
|
|
| |
llvm-svn: 280223
|
|
|
|
| |
llvm-svn: 280222
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 280221
|
|
|
|
|
|
|
|
| |
These clang tests check diagnostics from the backend by giving it an unvectorizable loop. This loop is now vectorized :/
Make it really unvectorizable by making it unprofitable to ifconvert.
llvm-svn: 280220
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 280219
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 280218
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 280217
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 280216
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 280215
|
|
|
|
|
|
|
|
|
|
| |
xmm result
Add patterns to avoid inserting unnecessary zeroing shuffles when lowering fptrunc to (v)cvtpd2ps
Differential Revision: https://reviews.llvm.org/D23797
llvm-svn: 280214
|
|
|
|
| |
llvm-svn: 280213
|
|
|
|
|
|
|
|
|
| |
Patch removes VersionScriptParser class and moves the members to ScriptParser
It opens road for implementation of VERSION linkerscript command.
Differential revision: https://reviews.llvm.org/D23774
llvm-svn: 280212
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
opposing meanings.
As stated in PR28843:
we should handle command lines with
-target1-rel -target1-abs
--demangle --no-demangle
Patch implements this for specified options.
There are probably other conflicting options can exist,
so fix is called "partial".
Differential revision: https://reviews.llvm.org/D23867
llvm-svn: 280211
|
|
|
|
|
|
|
|
|
|
| |
This patch groups relative relocations in a single block
in combrelocs mode and adds DT_RELCOUNT or DT_RELACOUNT
tag to .dynamic section
Differential revision: https://reviews.llvm.org/D23661
llvm-svn: 280210
|
|
|
|
|
|
|
|
|
|
|
| |
DiscardPolicy is enum replacing several boolean options.
This approach is not only consistent with what we use for
unresolveds (UnresolvedPolicy), but also should help to solve a problem
of options with opposing meanings, mentioned in PR28843
Differential revision: https://reviews.llvm.org/D23868
llvm-svn: 280209
|
|
|
|
|
|
| |
cause of the problem
llvm-svn: 280208
|
|
|
|
|
|
|
|
|
|
| |
The rewrite of StringExtractor::GetHexMaxU32 changes functionality in a way which makes
lldb-server crash. The crash (assert) happens when parsing the "qRegisterInfo0" packet, because
the function tries to drop_front more bytes than the packet contains. It's not clear to me
whether we should consider this a bug in the caller or the callee, but it any case, it worked
before, so I am reverting this until we can figure out what the proper interface should be.
llvm-svn: 280207
|
|
|
|
|
|
|
|
|
|
| |
This approach is not only consistent with UnresolvedPolicy,
but also should help to solve a problem
of options with opposing meanings, mentioned in PR28843
Differential revision: https://reviews.llvm.org/D23869
llvm-svn: 280206
|
|
|
|
|
|
|
|
|
| |
Allows adding start and/or end symbols to special output sections,
like .eh_frame_hdr, which aren't lists of regular input sections.
Differential revision: https://reviews.llvm.org/D23716
llvm-svn: 280205
|
|
|
|
|
|
| |
PeekChar returns a character, we want the whole string there.
llvm-svn: 280204
|
|
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D24041
llvm-svn: 280203
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
https://github.com/llvm-mirror/lldb/commit/e80f43fd78fa0fbc04d2d59b5713acb5d06c8308
greatly improved an API, but missed one more occurence of legacy usage.
This leads to:
if (extractor.GetHexBytes(&payload_bytes[0], payload_bytes.size(), '\xdd') != payload_bytes.size())
~~~~~~~~~~~~~~~~~~~~~ ^~~~~~
/lldb/include/lldb/Utility/StringExtractor.h:151:5: note: 'GetHexBytes' declared here
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D24064
Author: Taras Tsugrii <ttsugrii@fb.com>
llvm-svn: 280202
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Keep reifying other errors.
Reviewers: kcc, samsonov
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D23717
llvm-svn: 280201
|
|
|
|
| |
llvm-svn: 280200
|
|
|
|
|
|
|
|
|
|
|
|
| |
expansion region.
In most cases these code regions are just redundant, but sometimes they
could be assigned to the counter of the parent code region instead of
the counter of the nested block.
Differential Revision: https://reviews.llvm.org/D23987
llvm-svn: 280199
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 280198
|
|
|
|
|
|
| |
and remove the builtins.
llvm-svn: 280197
|
|
|
|
|
|
| |
These will be reused when removing some builtins from avx512vldqintrin.h and this will make the tests for that change show a better number of vector elements.
llvm-svn: 280196
|
|
|
|
|
|
|
|
| |
a floating point type.
This is needed in order to replace the masked floating point logical op intrinsics with native IR.
llvm-svn: 280195
|
|
|
|
|
|
|
|
| |
bitcasts between the logic ops and the select. We don't currently select masked operations for these cases.
Test cases taken from optimized clang output after trying to convert the masked floating point logical op intrinsics to native IR.
llvm-svn: 280194
|
|
|
|
| |
llvm-svn: 280193
|
|
|
|
|
|
|
| |
Add a .mir test to catch this case, and fix the xray-instrumentation
pass to handle it appropriately.
llvm-svn: 280192
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 280191
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
within the instantiation of that same specialization. This could previously
happen for eagerly-instantiated function templates, variable templates,
exception specifications, default arguments, and a handful of other cases.
We still have an issue here for default template arguments that recursively
make use of themselves and likewise for substitution into the type of a
non-type template parameter, but in those cases we're producing a different
entity each time, so they should instead be caught by the instantiation depth
limit. However, currently we will typically run out of stack before we reach
it. :(
llvm-svn: 280190
|
|
|
|
|
|
|
|
|
| |
'cc1' is a valid sequence of hexadecimal and sometimes can occur in the path
when testing. This can lead to FileCheck matching the incorrect occurance
of the 'cc1' string and causing a test failure. Join two adjacent flags
together into one check to prevent this.
llvm-svn: 280189
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 280188
|
|
|
|
| |
llvm-svn: 280187
|
|
|
|
| |
llvm-svn: 280186
|
|
|
|
| |
llvm-svn: 280185
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 280184
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 280183
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Add the type-safe wrapper to the platform-specific implementation.
Reviewers: jlebar
Subscribers: jprice, parallel_libs-commits
Differential Revision: https://reviews.llvm.org/D24063
llvm-svn: 280182
|
|
|
|
| |
llvm-svn: 280181
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Bugfix for 27321. When the constructor of stored pointer
type is private then it is invalid to change it to
make_shared or make_unique.
Reviewers: alexfh, aaron.ballman, hokein
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D23343
llvm-svn: 280180
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
positions. Resolves PR29148.
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
llvm-svn: 280179
|
|
|
|
|
|
| |
target.
llvm-svn: 280178
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Make the Kernel class follow the pattern of the other classes. It now
has a type-safe user wrapper and a typeless, platform-specific handle.
Reviewers: jlebar
Subscribers: jprice, parallel_libs-commits
Differential Revision: https://reviews.llvm.org/D24043
llvm-svn: 280176
|