| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
unit tests"
This reverts commit r368021, it broke tests.
llvm-svn: 368035
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To support spilling/filling of scalable vectors we need a more generic
representation of a stack offset than simply 'int'.
For this we introduce the StackOffset struct, which comprises multiple
offsets sized by their respective MVTs. Byte-offsets will thus be a simple
tuple such as { offset, MVT::i8 }. Adding two byte-offsets will result in a
byte offset { offsetA + offsetB, MVT::i8 }. When two offsets have different
types, we can canonicalise them to use the same MVT, as long as their
runtime sizes are guaranteed to have the same size-ratio as they would have
at compile-time.
When we have both scalable- and fixed-size objects on the stack, we can
create an offset that is:
({ offset_fixed, MVT::i8 } + { offset_scalable, MVT::nxv1i8 })
The struct also contains a getForFrameOffset() method that is specific to
AArch64 and decomposes the frame-offset to be used directly in instructions
that operate on the stack or index into the stack.
Note: This patch adds StackOffset as an AArch64-only concept, but we would
like to make this a generic concept/struct that is supported by all
interfaces that take or return stack offsets (currently as 'int'). Since
that would be a bigger change that is currently pending on D32530 landing,
we thought it makes sense to first show/prove the concept in the AArch64
target before proposing to roll this out further.
Reviewers: thegameg, rovka, t.p.northover, efriedma, greened
Reviewed By: rovka, greened
Differential Revision: https://reviews.llvm.org/D61435
llvm-svn: 368024
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: jhenderson, rupprecht, MaskRay, grimar, labath
Reviewed By: rupprecht
Subscribers: seiya, mgorny, sbc100, hiraditya, aheejin, jakehehrlich, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65255
llvm-svn: 368021
|
|
|
|
|
|
|
|
|
| |
This updates all libraries and tools in LLVM Core to use 64-bit offsets
which directly or indirectly come to DataExtractor.
Differential Revision: https://reviews.llvm.org/D65638
llvm-svn: 368014
|
|
|
|
|
|
|
|
|
|
| |
Using 64-bit offsets is required to fully implement 64-bit DWARF.
As these classes are used in many different libraries they should
temporarily support both 32- and 64-bit offsets.
Differential Revision: https://reviews.llvm.org/D64006
llvm-svn: 368013
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is patch is part of a serie to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Reviewers: jfb
Subscribers: hiraditya, dexonsmith, llvm-commits, courbet
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65748
Address comments
llvm-svn: 368000
|
|
|
|
|
|
| |
(matching r367495)
llvm-svn: 367899
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds a two way mapping between the scalable vector IR type and
corresponding SelectionDAG ValueTypes.
Reviewers: craig.topper, jeroen.dobbelaere, fhahn, rengolin, greened, rovka
Reviewed By: greened
Differential Revision: https://reviews.llvm.org/D47770
llvm-svn: 367832
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is patch is part of a serie to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Reviewers: courbet, jfb, jakehehrlich
Subscribers: hiraditya, dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65521
Make getFunctionPtrAlign() return MaybeAlign
llvm-svn: 367817
|
|
|
|
|
|
| |
F_{None,Text,Append} are kept for compatibility since r334221.
llvm-svn: 367800
|
|
|
|
| |
llvm-svn: 367758
|
|
|
|
|
|
|
|
|
|
| |
For consistency with normal instructions and clarity when reading IR,
it's best to print the %0, %1, ... names of function arguments in
definitions.
Also modifies the parser to accept IR in that form for obvious reasons.
llvm-svn: 367755
|
|
|
|
| |
llvm-svn: 367742
|
|
|
|
| |
llvm-svn: 367740
|
|
|
|
|
|
|
| |
Test on ppc64le passed.
This fix https://bugs.llvm.org/show_bug.cgi?id=42702
llvm-svn: 367713
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ThreadSafeModule/ThreadSafeContext are used to manage lifetimes and locking
for LLVMContexts in ORCv2. Prior to this patch contexts were locked as soon
as an associated Module was emitted (to be compiled and linked), and were not
unlocked until the emit call returned. This could lead to deadlocks if
interdependent modules that shared contexts were compiled on different threads:
when, during emission of the first module, the dependence was discovered the
second module (which would provide the required symbol) could not be emitted as
the thread emitting the first module still held the lock.
This patch eliminates this possibility by moving to a finer-grained locking
scheme. Each client holds the module lock only while they are actively operating
on it. To make this finer grained locking simpler/safer to implement this patch
removes the explicit lock method, 'getContextLock', from ThreadSafeModule and
replaces it with a new method, 'withModuleDo', that implicitly locks the context,
calls a user-supplied function object to operate on the Module, then implicitly
unlocks the context before returning the result.
ThreadSafeModule TSM = getModule(...);
size_t NumFunctions = TSM.withModuleDo(
[](Module &M) { // <- context locked before entry to lambda.
return M.size();
});
Existing ORCv2 layers that operate on ThreadSafeModules are updated to use the
new method.
This method is used to introduce Module locking into each of the existing
layers.
llvm-svn: 367686
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The unit tests in BasicAliasAnalysisTest use the alias analysis API
directly and do not call setAAResults to initalize AAR. This gives a
valgrind error "Conditional Jump depends on unitialized variable".
On most buildbots the variable is nullptr, but in some cases it can be
non nullptr leading to seemingly random failures.
These tests were disabled in r366986. With the initialization they can be
enabled again.
Fixes PR42719
Differential Revision: https://reviews.llvm.org/D65568
llvm-svn: 367662
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
exists.
Summary:
LoopSimplify is preserved in the legacy pass manager, but not in the new pass manager.
Update LoopSimplify to preserve MemorySSA conditionally when the analysis is available (same behavior as the legacy pass manager).
Reviewers: chandlerc
Subscribers: mehdi_amini, jlebar, Prazek, george.burgess.iv, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65418
llvm-svn: 367594
|
|
|
|
|
|
|
| |
AMDGPU testcase isn't broken now, but will be in a future patch
without this.
llvm-svn: 367591
|
|
|
|
|
|
|
|
|
|
|
| |
Adds a method which, when called with function.getArg(i), returns an
Argument* to the i'th argument.
Patch by Henry Wildermuth
Differential Revision: https://reviews.llvm.org/D64925
llvm-svn: 367576
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: asb
Reviewed By: asb
Subscribers: lenary, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, lebedev.ri, kito-cheng, shiva0217, rogfer01, dexonsmith, rkruppe, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D63497
Patch by Andreas Schwab (schwab)
llvm-svn: 367565
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: yroux
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65563
llvm-svn: 367532
|
|
|
|
| |
llvm-svn: 367495
|
|
|
|
|
|
|
|
| |
Added AddOverflow, SubOverflow and MulOverflow to compute truncated results and return a flag indicating whether overflow occured.
Differential Revision: https://reviews.llvm.org/D65494
llvm-svn: 367470
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Re-commit r366322 after some fixes
TME is a future architecture technology, documented in
https://developer.arm.com/architectures/cpu-architecture/a-profile/exploration-tools
https://developer.arm.com/docs/ddi0601/a
More about the future architectures:
https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/new-technologies-for-the-arm-a-profile-architecture
This patch adds support for the TME instructions TSTART, TTEST, TCOMMIT, and
TCANCEL and the target feature/arch extension "tme".
It also implements TME builtin functions, defined in ACLE Q2 2019
(https://developer.arm.com/docs/101028/latest)
Differential Revision: https://reviews.llvm.org/D64416
Patch by Javed Absar and Momchil Velikov
llvm-svn: 367428
|
|
|
|
| |
llvm-svn: 367427
|
|
|
|
| |
llvm-svn: 367404
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch introduces a type to straighten LLVM's alignment management.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
The next step is to use this type throughout LLVM
Reviewers: jfb, jakehehrlich
Subscribers: mgorny, mgrang, dexonsmith, llvm-commits, courbet
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64790
llvm-svn: 367393
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: The minimum compilers support all have alignas, and we don't use LLVM_ALIGNAS anywhere anymore. This also removes an MSVC diagnostic which, according to the comment above, isn't relevant anymore.
Reviewers: rnk
Subscribers: mgorny, jkorous, dexonsmith, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D65458
llvm-svn: 367383
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a new serializer, using a binary format based on the LLVM bitstream
format.
This format provides a way to serialize the remarks in two modes:
1) Separate mode: the metadata is separate from the remark entries.
2) Standalone mode: the metadata and the remark entries are in the same
file.
The format contains:
* a meta block: container version, container type, string table,
external file path, remark version
* a remark block: type, remark name, pass name, function name, debug
file, debug line, debug column, hotness, arguments (key, value, debug
file, debug line, debug column)
A string table is required for this format, which will be dumped in the
meta block to be consumed before parsing the remark blocks.
On clang itself, we noticed a size reduction of 13.4x compared to YAML,
and a compile-time reduction of between 1.7% and 3.5% on CTMark.
Differential Revision: https://reviews.llvm.org/D63466
Original llvm-svn: 367364
Revert llvm-svn: 367370
llvm-svn: 367372
|
|
|
|
|
|
|
|
| |
This reverts commit r367364.
Breaks some bots: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-gn/builds/3161/steps/annotate/logs/stdio
llvm-svn: 367370
|
|
|
|
| |
llvm-svn: 367369
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a new serializer, using a binary format based on the LLVM bitstream
format.
This format provides a way to serialize the remarks in two modes:
1) Separate mode: the metadata is separate from the remark entries.
2) Standalone mode: the metadata and the remark entries are in the same
file.
The format contains:
* a meta block: container version, container type, string table,
external file path, remark version
* a remark block: type, remark name, pass name, function name, debug
file, debug line, debug column, hotness, arguments (key, value, debug
file, debug line, debug column)
A string table is required for this format, which will be dumped in the
meta block to be consumed before parsing the remark blocks.
On clang itself, we noticed a size reduction of 13.4x compared to YAML,
and a compile-time reduction of between 1.7% and 3.5% on CTMark.
Differential Revision: https://reviews.llvm.org/D63466
llvm-svn: 367364
|
|
|
|
|
|
|
|
|
|
| |
The default mode is separate, where the metadata is serialized
separately from the remarks.
Another mode is the standalone mode, where the metadata is serialized
before the remarks, on the same stream.
llvm-svn: 367328
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Equivalent to `x & -2^K`.
Reviewers: RKSimon, craig.topper
Reviewed By: RKSimon, craig.topper
Subscribers: dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65369
llvm-svn: 367287
|
|
|
|
|
|
|
|
|
| |
I removed all uses of AlignedCharArray since the minimum MSVC version can handle
alignas on char arrays correctly. We can therefore remove AlignedCharArray.
This patch also updates AlignedCharArrayUnion to use C++11.
llvm-svn: 367282
|
|
|
|
|
|
|
| |
Looks like one of the entries isn't found on windows. I'm investigating why.
In the meantime, I'll disable this part of the test on windows.
llvm-svn: 367280
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a VFS that can be overlaid on top of another VFS
to record file system accesses using the FileCollector.
This can help to gather files that are needed for reproducers.
Differential Revision: https://reviews.llvm.org/D65411
llvm-svn: 367278
|
|
|
|
| |
llvm-svn: 367161
|
|
|
|
|
|
| |
"no such file or directory" vs "No such file or directory"
llvm-svn: 367159
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support to the yaml remark parser to be able to parse remarks
directly from the metadata.
This supports parsing separate metadata and following the external file
with the associated metadata, and also a standalone file containing
metadata + remarks all together.
Original llvm-svn: 367148
Revert llvm-svn: 367151
This has a fix for gcc builds.
llvm-svn: 367155
|
|
|
|
|
|
|
|
|
| |
This reverts r367148.
Seems to fail on
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fuzzer/builds/27768.
llvm-svn: 367151
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support to the yaml remark parser to be able to parse remarks
directly from the metadata.
This supports parsing separate metadata and following the external file
with the associated metadata, and also a standalone file containing
metadata + remarks all together.
llvm-svn: 367148
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The bitperm feature flag is now prefixed with SVE2, as it is for all other SVE2
extensions
Patch by Maciej Gabka.
Reviewers: sdesmalen, rovka, chill, SjoerdMeijer, rengolin
Reviewed By: SjoerdMeijer, rengolin
Differential Revision: https://reviews.llvm.org/D65327
llvm-svn: 367124
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows every serializer format to implement metaSerializer() and
return the corresponding meta serializer.
Original llvm-svn: 366946
Reverted llvm-svn: 367004
This fixes the unit tests on Windows bots.
llvm-svn: 367078
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The file collector class is useful for constructing reproducers by
creating a snapshot of the files that are accessed. Sometimes it might
also be important to construct directories that don't necessarily have files,
but are still accessed by some tool that we want to make a reproducer for.
This is useful for instance for modeling the behavior of Clang's header search,
which scans through a number of directories it doesn't actually access when
looking for framework headers. This commit extends the file collector to allow
it to work with paths that are just directories, by constructing them as the
files are copied over.
Differential Revision: https://reviews.llvm.org/D65297
llvm-svn: 367061
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
as DDG and PDG.
Summary:
This is an implementation of a directed graph base class with explicit
representation of both nodes and edges. This implementation makes the
edges explicit because we expect to assign various attributes (such as
dependence type, distribution interference weight, etc) to the edges in
the derived classes such as DDG and DIG. The DirectedGraph consists of a
list of DGNode's. Each node consists of a (possibly empty) list of
outgoing edges to other nodes in the graph. A DGEdge contains a
reference to a single target node. Note that nodes do not know about
their incoming edges so the DirectedGraph class provides a function to
find all incoming edges to a given node.
This is the first patch in a series of patches that we are planning to
contribute upstream in order to implement Data Dependence Graph and
Program Dependence Graph.
More information about the proposed design can be found here:
https://ibm.ent.box.com/v/directed-graph-and-ddg
Authored By: bmahjour
Reviewer: Meinersbur, myhsum hfinkel, fhahn, jdoerfert, kbarton
Reviewed By: Meinersbur
Subscribers: mgorny, wuzish, jsji, lebedev.ri, dexonsmith, kristina,
llvm-commits, Whitney, etiotto
Tag: LLVM
Differential Revision: https://reviews.llvm.org/D64088
llvm-svn: 367043
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is the first patch for the loop guard. We introduced
getLoopGuardBranch() and isGuarded().
This currently only works on simplified loop, as it requires a preheader
and a latch to identify the guard.
It will work on loops of the form:
/// GuardBB:
/// br cond1, Preheader, ExitSucc <== GuardBranch
/// Preheader:
/// br Header
/// Header:
/// ...
/// br Latch
/// Latch:
/// br cond2, Header, ExitBlock
/// ExitBlock:
/// br ExitSucc
/// ExitSucc:
Prior discussions leading upto the decision to introduce the loop guard
API: http://lists.llvm.org/pipermail/llvm-dev/2019-May/132607.html
Reviewer: reames, kbarton, hfinkel, jdoerfert, Meinersbur, dmgreen
Reviewed By: reames
Subscribers: wuzish, hiraditya, jsji, llvm-commits, bmahjour, etiotto
Tag: LLVM
Differential Revision: https://reviews.llvm.org/D63885
llvm-svn: 367033
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
It is a good idea to do as much matching inside of `match()` as possible.
If some checking is done afterwards, and we don't fold because of it,
chances are we may have missed some commutative pattern.
Reviewers: spatel, craig.topper, RKSimon
Reviewed By: spatel, RKSimon
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64038
llvm-svn: 367017
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
I don't think it already exists? I don't see it at least.
It is important to have it because else we'll do some checks after `match()`,
and that may result in missed folds in commutative nodes.
Reviewers: spatel, craig.topper, RKSimon, majnemer
Reviewed By: spatel
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64037
llvm-svn: 367016
|