| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
There aren't very many requirements on the legalization rules but we should
document them.
Reviewers: aditya_nandakumar, volkan, bogner, paquette, aemerson, rovka, arsenm, Petar.Avramovic
Subscribers: wdng, kristof.beyls, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62423
# Conflicts:
# llvm/docs/GlobalISel.rst
llvm-svn: 368321
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some targets the LICM pass can result in sub-optimal code in some
cases where it would be better not to run the pass, but it isn't
always possible to suppress the transformations heuristically.
Where the front-end has insight into such cases it is beneficial
to attach loop metadata to disable the pass - this change adds the
llvm.licm.disable metadata to enable that.
Differential Revision: https://reviews.llvm.org/D64557
llvm-svn: 368296
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
flags
Summary:
The information for -info -thin -create -replace and -segalign flags are added to llvm-lipo.rst
Test Plan:
Reviewers: smeenai, alexshap, compnerd, mtrent
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65676
llvm-svn: 368235
|
|
|
|
|
|
| |
This reverts r368071 (git commit a2584978f5bb41973d65a145b0d9459b81e3ac6d)
llvm-svn: 368217
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Tool parses input IR file, and runs the delta debugging algorithm to reduce the functions inside the input file.
Reviewers: alexshap, chandlerc
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63672
> llvm-svn: 368071
llvm-svn: 368214
|
|
|
|
| |
llvm-svn: 368167
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commits:
"Added Delta IR Reduction Tool"
"[Bugpoint redesign] Added Pass to Remove Global Variables"
"Added Tool as Dependency to tests & fixed warnings"
Reduce/remove-funcs.ll is failing on bots.
llvm-svn: 368122
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Tool parses input IR file, and runs the delta debugging algorithm to reduce the functions inside the input file.
Reviewers: alexshap, chandlerc
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63672
> llvm-svn: 368071
llvm-svn: 368112
|
|
|
|
|
|
| |
This reverts commit r368071, it broke buildbots.
llvm-svn: 368073
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Tool parses input IR file, and runs the delta debugging algorithm to reduce the functions inside the input file.
Reviewers: alexshap, chandlerc
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63672
llvm-svn: 368071
|
|
|
|
|
|
|
|
| |
optimization"
The note was moved to the release_90 branch in r367997.
llvm-svn: 367998
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A function is "no-return" if we never reach a return instruction, either
because there are none or the ones that exist are dead.
Test have been adjusted:
- either noreturn was added, or
- noreturn was avoided by modifying the code.
The new noreturn_{sync,async} test make sure we do handle invoke
instructions with a noreturn (and potentially nowunwind) callee
correctly, even in the presence of potential asynchronous exceptions.
llvm-svn: 367948
|
|
|
|
|
|
|
|
|
|
| |
--stack-sizes
Reviewers: jhenderson, grimar, rupprecht
Differential Revision: https://reviews.llvm.org/D65313
llvm-svn: 367942
|
|
|
|
|
|
| |
This has come up twice already (once in pr42763 and once in the commit thread), so give warning of a new way in which UB can result in unexpected program behavior.
llvm-svn: 367941
|
|
|
|
|
|
| |
Also clarify the meaning of 'Block RThroughput' and 'RThroughput'.
llvm-svn: 367853
|
|
|
|
|
|
| |
F_{None,Text,Append} are kept for compatibility since r334221.
llvm-svn: 367800
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, debuginfo types are annotated to
IR builtin preserve_struct_access_index() and
preserve_union_access_index(), but not
preserve_array_access_index(). The debug info
is useful to identify the root type name which
later will be used for type comparison.
For user access without explicit type conversions,
the previous scheme works as we can ignore intermediate
compiler generated type conversions (e.g., from union types to
union members) and still generate correct access index string.
The issue comes with user explicit type conversions, e.g.,
converting an array to a structure like below:
struct t { int a; char b[40]; };
struct p { int c; int d; };
struct t *var = ...;
... __builtin_preserve_access_index(&(((struct p *)&(var->b[0]))->d)) ...
Although BPF backend can derive the type of &(var->b[0]),
explicit type annotation make checking more consistent
and less error prone.
Another benefit is for multiple dimension array handling.
For example,
struct p { int c; int d; } g[8][9][10];
... __builtin_preserve_access_index(&g[2][3][4].d) ...
It would be possible to calculate the number of "struct p"'s
before accessing its member "d" if array debug info is
available as it contains each dimension range.
This patch enables to annotate IR builtin preserve_array_access_index()
with proper debuginfo type. The unit test case and language reference
is updated as well.
Signed-off-by: Yonghong Song <yhs@fb.com>
Differential Revision: https://reviews.llvm.org/D65664
llvm-svn: 367724
|
|
|
|
|
|
| |
Addresses PR42864.
llvm-svn: 367689
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
masm binary and hex literals.
This patch adds a new llvm-mca flag named -print-imm-hex.
By default, the instruction printer prints immediate operands as decimals. Flag
-print-imm-hex enables the instruction printer to print those operands in hex.
This patch also adds support for MASM binary and hex literal numbers (example
0FFh, 101b).
Added tests to verify the behavior of the new flag. Tests also verify that masm
numeric literal operands are now recognized.
Differential Revision: https://reviews.llvm.org/D65588
llvm-svn: 367671
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The note in the documentation suggests this restriction is a compile
time optimization for architectures that make heavy use of
bundling. Allowing virtual registers in a bundle is useful for some
(non-R600) AMDGPU use cases and are infrequent enough to matter.
A more common AMDGPU use case has already been using virtual registers
in bundles since r333691, although never calling finalizeBundle on
them and manually creating the use/def list on the BUNDLE
instruction. This is also relatively infrequent, and only happens for
consecutive sequences of some load/store types.
llvm-svn: 367597
|
|
|
|
| |
llvm-svn: 367585
|
|
|
|
| |
llvm-svn: 367584
|
|
|
|
| |
llvm-svn: 367487
|
|
|
|
|
|
| |
Thanks to Stefan Granitz for catching the issue.
llvm-svn: 367458
|
|
|
|
|
|
|
|
|
| |
The build failure found after the rL365467 has been
resolved.
Differential Revision: https://reviews.llvm.org/D60716
llvm-svn: 367446
|
|
|
|
|
|
|
|
| |
In the approval of D65299, commited as rL367440, I mentioned that my
proposed wording was lacking the word "maximal". It is added now for
correctness.
llvm-svn: 367445
|
|
|
|
|
|
|
|
|
| |
Add user enabled option to create lipo with symlink to llvm-lipo
Used rL326381 for reference.
Differential Revision: https://reviews.llvm.org/D65477
llvm-svn: 367444
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Given the example:
header:
br i1 %c, label %next, label %header
next:
br i1 %c2, label %exit, label %header
We end up with a loop containing both header and next. Given that, the describing the loop in terms of cycles is confusing since we have multiple distinct cycles within a single Loop. Standardize on the SCC to clarify.
Differential Revision: https://reviews.llvm.org/D65299
llvm-svn: 367440
|
|
|
|
|
|
|
|
|
| |
Add cmake to the list of packages required for compiling LLVM.
Also move make to the bottom of the list and mark it as optional.
Differential Revision: https://reviews.llvm.org/D65438
llvm-svn: 367395
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
return_call and return_call_indirect are only valid if the return
types of the callee and caller match. We were previously not enforcing
that, which was producing invalid modules.
Reviewers: aheejin
Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65246
llvm-svn: 367339
|
|
|
|
|
|
|
|
|
|
| |
The path to the image was outdated.
http://lab.llvm.org:8011/builders/llvm-sphinx-docs/builds/33865/steps/docs-llvm-html/logs/stdio
llvm/docs/tutorial/OCamlLangImpl5.rst:173: WARNING: image file not readable: tutorial/LangImpl05-cfg.png
llvm-svn: 367334
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
This patch enables support for --add-section=... option for COFF objects.
Differential Revision: https://reviews.llvm.org/D65040
llvm-svn: 367130
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a new vectorize predication loop hint:
#pragma clang loop vectorize_predicate(enable)
that can be used to indicate to the vectoriser that all (load/store)
instructions should be predicated (masked). This allows, for example, folding
of the remainder loop into the main loop.
This patch will be followed up with D64916 and D65197. The former is a
refactoring in the loopvectorizer and the groundwork to make tail loop folding
a more general concept, and in the latter the actual tail loop folding
transformation will be implemented.
Differential Revision: https://reviews.llvm.org/D64744
llvm-svn: 366989
|
|
|
|
| |
llvm-svn: 366964
|
|
|
|
| |
llvm-svn: 366961
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've noticed a lot of confusion around this area recently with key terms being misused in a number of threads. To help reign that in, let's go ahead and document the current terminology and meaning thereof.
My hope is to grow this over time into a broader discussion of canonical loop forms - yes, there are more than one ... many more than one - but for the moment, simply having the key terminology is a good stopping place.
Note: I am landing this *without* an LGTM. All feedback so far has been positive, and trying to apply all of the suggested changes/extensions would cause the review to never end. Instead, I decided to land it with the obvious fixes made based on reviewer comments, then iterate from there.
Differential Revision: https://reviews.llvm.org/D65164
llvm-svn: 366960
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch is part of a patch series to add support for FileCheck
numeric expressions. This specific patch lift the restriction for a
numeric expression to either be a variable definition or a numeric
expression to try to match.
This commit allows a numeric variable to be set to the result of the
evaluation of a numeric expression after it has been matched
successfully. When it happens, the variable is allowed to be used on
the same line since its value is known at match time.
It also makes use of this possibility to reuse the parsing code to
parse a command-line definition by crafting a mirror string of the
-D option with the equal sign replaced by a colon sign, e.g. for option
'-D#NUMVAL=10' it creates the string
'-D#NUMVAL=10 (parsed as [[#NUMVAL:10]])' where the numeric expression
is parsed to define NUMVAL. This result in a few tests needing updating
for the location diagnostics on top of the tests for the new feature.
It also enables empty numeric expression which match any number without
defining a variable. This is done here rather than in commit #5 of the
patch series because it requires to dissociate automatic regex insertion
in RegExStr from variable definition which would make commit #5 even
bigger than it already is.
Copyright:
- Linaro (changes up to diff 183612 of revision D55940)
- GraphCore (changes in later versions of revision D55940 and
in new revision created off D55940)
Reviewers: jhenderson, chandlerc, jdenny, probinson, grimar, arichardson, rnk
Subscribers: hiraditya, llvm-commits, probinson, dblaikie, grimar, arichardson, tra, rnk, kristina, hfinkel, rogfer01, JonChesterfield
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60388
> llvm-svn: 366860
llvm-svn: 366897
|
|
|
|
|
|
| |
This reverts commit 1b05977538d9487aa845ee2f3bec8b89c63c4f29.
llvm-svn: 366872
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch is part of a patch series to add support for FileCheck
numeric expressions. This specific patch lift the restriction for a
numeric expression to either be a variable definition or a numeric
expression to try to match.
This commit allows a numeric variable to be set to the result of the
evaluation of a numeric expression after it has been matched
successfully. When it happens, the variable is allowed to be used on
the same line since its value is known at match time.
It also makes use of this possibility to reuse the parsing code to
parse a command-line definition by crafting a mirror string of the
-D option with the equal sign replaced by a colon sign, e.g. for option
'-D#NUMVAL=10' it creates the string
'-D#NUMVAL=10 (parsed as [[#NUMVAL:10]])' where the numeric expression
is parsed to define NUMVAL. This result in a few tests needing updating
for the location diagnostics on top of the tests for the new feature.
It also enables empty numeric expression which match any number without
defining a variable. This is done here rather than in commit #5 of the
patch series because it requires to dissociate automatic regex insertion
in RegExStr from variable definition which would make commit #5 even
bigger than it already is.
Copyright:
- Linaro (changes up to diff 183612 of revision D55940)
- GraphCore (changes in later versions of revision D55940 and
in new revision created off D55940)
Reviewers: jhenderson, chandlerc, jdenny, probinson, grimar, arichardson, rnk
Subscribers: hiraditya, llvm-commits, probinson, dblaikie, grimar, arichardson, tra, rnk, kristina, hfinkel, rogfer01, JonChesterfield
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60388
llvm-svn: 366860
|
|
|
|
|
|
|
|
| |
This is based on https://bugs.llvm.org/show_bug.cgi?id=42435#c3.
Patch by Ralf Jung.
llvm-svn: 366855
|