| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 336203
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Scudo works on PPC64 as is, so mark the architecture as supported for it. This
will also require a change to config-ix.cmake on the compiler-rt side.
Update the tests accordingly.
Reviewers: eugenis, alekseyshl
Reviewed By: alekseyshl
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48833
llvm-svn: 336202
|
| |
|
|
| |
llvm-svn: 336201
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: The new API allows to find a list of compile units related to target/module.
Reviewers: aprantl, clayborg
Reviewed By: aprantl
Subscribers: jingham, lldb-commits
Differential Revision: https://reviews.llvm.org/D48801
llvm-svn: 336200
|
| |
|
|
|
|
|
| |
Minor follow up for r336197
"[ELF] - Add support for '||' and '&&' in linker scripts."
llvm-svn: 336199
|
| |
|
|
|
|
| |
Now that D45806 has landed, we can re-enable support for MIN_SIGNED_VALUE in the sdiv by pow2-constant code
llvm-svn: 336198
|
| |
|
|
|
|
|
| |
This is https://bugs.llvm.org//show_bug.cgi?id=37976,
we had no support, but seems someone faced it.
llvm-svn: 336197
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the last significant change suggested in PR37806:
https://bugs.llvm.org/show_bug.cgi?id=37806#c5
...though there are several follow-ups noted in the code comments
in this patch to complete this transform.
It's possible that a binop feeding a select-shuffle has been eliminated
by earlier transforms (or the code was just written like this in the 1st
place), so we'll fail to match the patterns that have 2 binops from:
D48401,
D48678,
D48662,
D48485.
In that case, we can try to materialize identity constants for the remaining
binop to fill in the "ghost" lanes of the vector (where we just want to pass
through the original values of the source operand).
I added comments to ConstantExpr::getBinOpIdentity() to show planned follow-ups.
For now, we only handle the 5 commutative integer binops (add/mul/and/or/xor).
Differential Revision: https://reviews.llvm.org/D48830
llvm-svn: 336196
|
| |
|
|
|
|
|
|
|
|
| |
With a view to support parallel operations that have their results
stored to memory, refactor the consecutive access helper out so it
could support stores instructions.
Differential Revision: https://reviews.llvm.org/D48872
llvm-svn: 336195
|
| |
|
|
| |
llvm-svn: 336194
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the following system registers:
- RAS registers,
- MPAM registers,
- Activitiy monitor registers,
- Trace Extension registers,
- Timing insensitivity of data processing instructions,
- Enhanced Support for Nested Virtualization.
Differential Revision: https://reviews.llvm.org/D48871
llvm-svn: 336193
|
| |
|
|
|
|
| |
The build on Windows has been extra flaky recently; retrying helps.
llvm-svn: 336192
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When salvaging a dbg.declare/dbg.addr we should not add
DW_OP_stack_value to the DIExpression
(see test/Transforms/InstCombine/salvage-dbg-declare.ll).
Consider this example
%vla = alloca i32, i64 2
call void @llvm.dbg.declare(metadata i32* %vla, metadata !1, metadata !DIExpression())
Instcombine will turn it into
%vla1 = alloca [2 x i32]
%vla1.sub = getelementptr inbounds [2 x i32], [2 x i32]* %vla, i64 0, i64 0
call void @llvm.dbg.declare(metadata [2 x i32]* %vla1.sub, metadata !19, metadata !DIExpression())
If the GEP can be eliminated, then the dbg.declare will be salvaged
and we should get
%vla1 = alloca [2 x i32]
call void @llvm.dbg.declare(metadata [2 x i32]* %vla1, metadata !19, metadata !DIExpression())
The problem was that salvageDebugInfo did not recognize dbg.declare
as being indirect (%vla1 points to the value, it does not hold the
value), so we incorrectly got
call void @llvm.dbg.declare(metadata [2 x i32]* %vla1, metadata !19, metadata !DIExpression(DW_OP_stack_value))
I also made sure that llvm::salvageDebugInfo and
DIExpression::prependOpcodes do not add DW_OP_stack_value to
the DIExpression in case no new operands are added to the
DIExpression. That way we avoid to, unneccessarily, turn a
register location expression into an implicit location expression
in some situations (see test11 in test/Transforms/LICM/sinking.ll).
Reviewers: aprantl, vsk
Reviewed By: aprantl, vsk
Subscribers: JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D48837
llvm-svn: 336191
|
| |
|
|
|
|
| |
This reverts commit r336113. It causes crashes.
llvm-svn: 336189
|
| |
|
|
|
|
|
| |
The signature of setRegToConstant changed in r336171, so adjust the AArch64
unit test in a similar way to how the X86 unit test was changed in that commit.
llvm-svn: 336188
|
| |
|
|
|
|
|
|
|
| |
The target does just enough to be able to run llvm-exegesis in latency mode for
at least some opcodes.
Differential Revision: https://reviews.llvm.org/D48780
llvm-svn: 336187
|
| |
|
|
|
|
|
|
|
|
| |
The variants added are:
signed Saturating ADD/SUB (immediate) e.g. sqadd z0.h, z0.h, #42
unsigned Saturating ADD/SUB (immediate) e.g. uqadd z0.h, z0.h, #42
signed Saturating ADD/SUB (vectors) e.g. sqadd z0.h, z0.h, z1.h
unsigned Saturating ADD/SUB (vectors) e.g. uqadd z0.h, z0.h, z1.h
llvm-svn: 336186
|
| |
|
|
|
|
|
|
|
|
|
| |
Lower more than 4 arguments using stack. This patch targets MIPS32.
It supports only functions with arguments of type i32.
Patch by Petar Avramovic.
Differential Revision: https://reviews.llvm.org/D47934
llvm-svn: 336185
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLD removes empty output sections otherwise specified in the linker
script. Prior to this change however, if section descriptions included
ANY kind of symbol assignment, then the consequent output section would
not be removed, even if the assignment was marked with PROVIDE and not
actually triggered (i.e. the symbol was never referenced). This change
modifies the isDiscarable function to ignore such directives when
determining whether a section should be discarded, in keeping with
bfd's behaviour. Symbol assignments that do result in a symbol
definition will continue to result in a kept section (this is not
actually the same as bfd's behaviour, but it is simpler, and probably
makes more sense).
Reviewed By: grimar
Differential Revision: https://reviews.llvm.org/D48771
llvm-svn: 336184
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unswitching loops.
Original patch trying to address this was sent in D47624, but that
didn't quite handle things correctly. There are two key principles used
to select whether and how to invalidate SCEV-cached information about
loops:
1) We must invalidate any info SCEV has cached before unswitching as we
may change (or destroy) the loop structure by the act of unswitching,
and make it hard to recover everything we want to invalidate within
SCEV.
2) We need to invalidate all of the loops whose CFGs are mutated by the
unswitching. Notably, this isn't the *entire* loop nest, this is
every loop contained by the outermost loop reached by an exit block
relevant to the unswitch.
And we need to do this even when doing trivial unswitching.
I've added more focused tests that directly check that SCEV starts off
with imprecise information and after unswitching (and simplifying
instructions) re-querying SCEV will produce precise information. These
tests also specifically work to check that an *outer* loop's information
becomes precise.
However, the testing here is still a bit imperfect. Crafting test cases
that reliably fail to be analyzed by SCEV before unswitching and succeed
afterward proved ... very, very hard. It took me several hours and
careful work to build these, and I'm not optimistic about necessarily
coming up with more to cover more elaborate possibilities. Fortunately,
the code pattern we are testing here in the pass is really
straightforward and reliable.
Thanks to Max Kazantsev for the initial work on this as well as the
review, and to Hal Finkel for helping me talk through approaches to test
this stuff even if it didn't come to much.
Differential Revision: https://reviews.llvm.org/D47624
llvm-svn: 336183
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Contains the following variants:
- Compare with (elements from) other vector
instructions: fcmeq, fcmgt, fcmge, fcmne, fcmuo.
aliases: fcmle, fcmlt.
e.g. fcmle p0.h, p0/z, z0.h, z1.h => fcmge p0.h, p0/z, z1.h, z0.h
- Compare absolute values with (absolute values from) other vector.
instructions: facge, facgt.
aliases: facle, faclt.
e.g. facle p0.h, p0/z, z0.h, z1.h => facge p0.h, p0/z, z1.h, z0.h
- Compare vector elements with #0.0
instructions: fcmeq, fcmgt, fcmge, fcmle, fcmlt, fcmne.
e.g. fcmle p0.h, p0/z, z0.h, #0.0
llvm-svn: 336182
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The AArch64 -fix-cortex-a53-843419 is missing a test case for the load and
store exclusive instructions. This was leading to a function not being
covered in the codebase. This change adds two new instruction sequences to
be recognised as an instance of the erratum, one with a load exclusive the
other with a store exclusive.
Differential Revision: https://reviews.llvm.org/D48840
llvm-svn: 336181
|
| |
|
|
|
|
| |
This restores the original comment in the test case.
llvm-svn: 336180
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Comment in the test case says that:
## This inputs previously created a 4gb temporarily file under 32 bit
## configuration. Issue was fixed. There is no clean way to check that from here.
## This testcase added for documentation purposes.
The intention of the test was to create such huge file
in case if our code will be broken again.
And currently it documents we do not create huge outputs.
r336129 changed -o to /dev/null and broke the intentions of the test case.
llvm-svn: 336179
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
It appears that the function pointer we use there isn't reliably 4-byte
aligned. I have no idea why or how we could correct this, so for now we
just regress the Windows performance some.
Someone with access to Windows could try working on a fix. At the very
least we could use a double indirection rather than a table, but maybe
there is some way to fully restore this optimization. I don't want to
play too much with this when I don't have access to the platform and
this at least should restore the last bots.
llvm-svn: 336178
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We now compute a distance from the main file to the symbol header, which
is a weighted count of:
- some number of #include traversals from source file --> included file
- some number of FS traversals from file --> parent directory
- some number of FS traversals from parent directory --> child file/dir
This calculation is performed in the appropriate URI scheme.
This means we'll get some proximity boost from header files in main-file
contexts, even when these are in different directory trees.
This extended file proximity model is not yet incorporated in the index
interface/implementation.
Reviewers: ioeric
Subscribers: mgorny, ilya-biryukov, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D48441
llvm-svn: 336177
|
| |
|
|
|
|
|
|
|
|
| |
DbgLabelInst has no address as its operands.
Differential Revision: https://reviews.llvm.org/D46738
Patch by Hsiangkai Wang.
llvm-svn: 336176
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
kind within"
This caused test failures in 32-bit builds (PR38015).
> merged function definitions; also merge functions with deduced return
> types.
>
> This seems like two independent fixes, but unfortunately they are hard
> to separate because it's challenging to reliably test either one of them
> without also testing the other.
>
> A complication arises with deduced return type support: we need the type
> of the function in order to know how to merge it, but we can't load the
> actual type of the function because it might reference an entity
> declared within the function (and we need to have already merged the
> function to correctly merge that entity, which we would need to do to
> determine if the function types match). So we instead compare the
> declared function type when merging functions, and defer loading the
> actual type of a function with a deduced type until we've finished
> loading and merging the function.
llvm-svn: 336175
|
| |
|
|
|
|
|
|
|
|
|
| |
of libstdc++, not just certain versions of GCC. The original macros
broke when using Clang + libstdc++4.9 sadly.
Sadly, testing for versions of libstdc++ has been extremely problematic
in the past, so I'm just narrowing this down to Windows and when using
libc++ as that seems at least very unlikely to keep build bots broken.
llvm-svn: 336174
|
| |
|
|
|
|
|
| |
This was never serialized, and embedders now have access to the
CodeCompletion API, which includes this information.
llvm-svn: 336173
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch changes order of transform in InstCombineCompares to avoid
performing transforms based on ranges which produce complex bit arithmetics
before more simple things (like folding with constants) are done. See PR37636
for the motivating example.
Differential Revision: https://reviews.llvm.org/D48584
Reviewed By: spatel, lebedev.ri
llvm-svn: 336172
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
subtarget features.
Summary: This fixes PR38008.
Reviewers: gchatelet, RKSimon
Subscribers: tschuett, craig.topper, llvm-commits
Differential Revision: https://reviews.llvm.org/D48820
llvm-svn: 336171
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Putting `sizeof(T) <= 16` into the parameter of a `std::conditional`
causes every version of MSVC I've tried to crash:
https://godbolt.org/g/eqVULL
Really frustrating, but an extra layer of indirection through an
instantiated type gives a working way to access this computed constant.
llvm-svn: 336170
|
| |
|
|
| |
llvm-svn: 336169
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When clang required to infer target os version from --target option and
the os version is not specified in targets, check the host triple. If the
host and target are both macOS, use host triple to infer target os
version.
rdar://problem/41651999
Reviewers: arphaman, dexonsmith
Reviewed By: arphaman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48849
llvm-svn: 336168
|
| |
|
|
|
|
| |
I missed this the first time around, sorry.
llvm-svn: 336166
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Omitted from D41347.
Reviewers: EricWF
Subscribers: mgorny, christof, ldionne, cfe-commits
Differential Revision: https://reviews.llvm.org/D48864
llvm-svn: 336165
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This is needed to implement `<charconv>`, otherwise `<charconv>` would need to include `<system_error>`, which pulls in `<string>` -- a header which the `<charconv>` proposal intends to keep away from.
Reviewers: mclow.lists, EricWF
Reviewed By: mclow.lists
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D41347
llvm-svn: 336164
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch is the first in a series of patches related to the [[ http://lists.llvm.org/pipermail/llvm-dev/2018-June/123883.html | RFC - A new dominator tree updater for LLVM ]].
This patch introduces the DomTreeUpdater class, which provides a cleaner API to perform updates on available dominator trees (none, only DomTree, only PostDomTree, both) using different update strategies (eagerly or lazily) to simplify the updating process.
—Prior to the patch—
- Directly calling update functions of DominatorTree updates the data structure eagerly while DeferredDominance does updates lazily.
- DeferredDominance class cannot be used when a PostDominatorTree also needs to be updated.
- Functions receiving DT/DDT need to branch a lot which is currently necessary.
- Functions using both DomTree and PostDomTree need to call the update function separately on both trees.
- People need to construct an additional DeferredDominance class to use functions only receiving DDT.
—After the patch—
Patch by Chijun Sima <simachijun@gmail.com>.
Reviewers: kuhar, brzycki, dmgreen, grosser, davide
Reviewed By: kuhar, brzycki
Author: NutshellySima
Subscribers: vsk, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D48383
llvm-svn: 336163
|
| |
|
|
|
|
|
|
|
|
|
| |
other on unqualified max_align_t.
I'll take another stab at this tomorrow. Any ideas for fixing this would be appreciated!
http://lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/23071/steps/build_Lld/logs/stdio
http://lab.llvm.org:8011/builders/clang-with-thin-lto-ubuntu/builds/11185/steps/build-stage1-compiler/logs/stdio
llvm-svn: 336162
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
introducing llvm::trivially_{copy,move}_constructible type traits.
This uses a completely portable implementation of these traits provided
by Richard Smith. You can see it on compiler explorer in all its glory:
https://godbolt.org/g/QEDZjW
I have transcribed it, clang-formatted it, added some comments, and made
the tests fit into a unittest file.
I have also switched llvm::unique_function over to use these new, much
more portable traits. =D
Hopefully this will fix the build bot breakage from my prior commit.
llvm-svn: 336161
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When we import an alias (which will import a copy of the aliasee), but
aren't going to import the aliasee directly, the distributed backend
index will not contain the aliasee summary. Handle this in the summary
assembly printer by printing "null" as the aliasee.
Reviewers: davidxl, dexonsmith
Subscribers: mehdi_amini, inglorion, eraman, steven_wu, llvm-commits
Differential Revision: https://reviews.llvm.org/D48699
llvm-svn: 336160
|
| |
|
|
| |
llvm-svn: 336159
|
| |
|
|
|
|
|
|
|
|
|
|
| |
that I used to sort it to scripts/sort-pbxproj.rb. It turns
out that Xcode will perturb the order of the file lists
every time we add a file, following its own logic, and unfortunately
we'll still end up with lots of merge conflicts when that tries
to merge to the github swift repositories. We talked this over
and we're going to keep it in a canonical state by running this
script over it when Xcode tries to reorder it.
llvm-svn: 336158
|
| |
|
|
|
|
| |
This should fix llvm.org/PR37944
llvm-svn: 336157
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
supporting move-only closures.
Most of the core optimizations for std::function are here plus
a potentially novel one that detects trivially movable and destroyable
functors and implements those with fewer indirections.
This is especially useful as we start trying to add concurrency
primitives as those often end up with move-only types (futures,
promises, etc) and wanting them to work through lambdas.
As further work, we could add better support for things like const-qualified
operator()s to support more algorithms, and r-value ref qualified operator()s
to model call-once. None of that is here though.
We can also provide our own llvm::function that has some of the optimizations
used in this class, but with copy semantics instead of move semantics.
This is motivated by increasing usage of things like executors and the task
queue where it is useful to embed move-only types like a std::promise within
a type erased function. That isn't possible without this version of a type
erased function.
Differential Revision: https://reviews.llvm.org/D48349
llvm-svn: 336156
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This patch updates exec-next-instruction, exec-step-instruction,
exec-finish, exec-interrupt commands to use SB API instead of HandleCommand.
Reviewers: aprantl, clayborg
Reviewed By: aprantl
Subscribers: ki.stfu, lldb-commits
Differential Revision: https://reviews.llvm.org/D48520
llvm-svn: 336155
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fixes the XCode builds that started failing when i added CompletionRequest.cpp/.h.
The patch is so large because XCode decided to write the lines back in its own order, but essentially we only added on e file.
Subscribers: srhines, lldb-commits
Differential Revision: https://reviews.llvm.org/D48858
llvm-svn: 336154
|
| |
|
|
|
|
| |
only invoke converting constructors of the reference's underlying type.
llvm-svn: 336153
|
| |
|
|
|
|
|
| |
My test change in r336148 accidentally included an absolute path, clean
that up to fix bot failures.
llvm-svn: 336151
|