Until recently, Python_ADDITIONAL_VERSIONS was used to limit LLVM's
Python support to 2.7. Now that both LLVM and LLDB both support Python
3, there's no longer a need to put an arbitrary limit on this.
However, instead of removing the variable, r365692 expanded the list,
which has the (presumably unintentional) side-effect of expression
preference for Python 3.
Instead, as Michal proposed in the original code review, we should just
not set the list at all, and let CMake pick whatever Python interpreter
you have in your path.
This patch removes the Python_ADDITIONAL_VERSIONS variable in llvm,
clang and lld. I've also updated the docs with the default behavior and
how to force a different Python version to be used.
Differential revision: https://reviews.llvm.org/D64894
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366447 91177308-0d34-0410-b5e6-96231b3b80d8
Before, everything was based on some kind of type erased parser
implementation which container a lot of boilerplate code when multiple
formats were to be supported.
This simplifies it by:
* the remark now owns its arguments
* *always* returning an error from the implementation side
* working around the way the YAML parser reports errors: catch them through
callbacks and re-insert them in a proper llvm::Error
* add a CParser wrapper that is used when implementing the C API to
avoid cluttering the C++ API with useless state
* LLVMRemarkParserGetNext now returns an object that needs to be
released to avoid leaking resources
* add a new API to dispose of a remark entry: LLVMRemarkEntryDispose
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366217 91177308-0d34-0410-b5e6-96231b3b80d8
Add "memtag" sanitizer that detects and mitigates stack memory issues
using armv8.5 Memory Tagging Extension.
It is similar in principle to HWASan, which is a software implementation
of the same idea, but there are enough differencies to warrant a new
sanitizer type IMHO. It is also expected to have very different
performance properties.
The new sanitizer does not have a runtime library (it may grow one
later, along with a "debugging" mode). Similar to SafeStack and
StackProtector, the instrumentation pass (in a follow up change) will be
inserted in all cases, but will only affect functions marked with the
new sanitize_memtag attribute.
Reviewers: pcc, hctim, vitalybuka, ostannard
Subscribers: srhines, mehdi_amini, javed.absar, kristof.beyls, hiraditya, cryptoad, steven_wu, dexonsmith, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D64169
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366123 91177308-0d34-0410-b5e6-96231b3b80d8
This is a followup patch for https://reviews.llvm.org/D61810/new/,
which adds new intrinsics preserve_{array,union,struct}_access_index.
Currently, only BPF backend utilizes preserve_{array,union,struct}_access_index
intrinsics, so all tests are compiled with BPF target.
https://reviews.llvm.org/D61524 already added some tests for these
intrinsics, but some of them pretty complex.
This patch added a few unit test cases focusing on individual intrinsic
functions.
Also made a few clarification on language reference for these intrinsics.
Differential Revision: https://reviews.llvm.org/D64606
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366038 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch is part of a patch series to add support for FileCheck
numeric expressions. This specific patch extend numeric expression to
support an arbitrary number of operands, either variable or literals.
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/D60387
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366001 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce and deduce "nosync" function attribute to indicate that a function
does not synchronize with another thread in a way that other thread might free memory.
Reviewers: jdoerfert, jfb, nhaehnle, arsenm
Subscribers: wdng, hfinkel, nhaenhle, mehdi_amini, steven_wu,
dexonsmith, arsenm, uenoku, hiraditya, jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D62766
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@365830 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Remove references to the multirepo and update the document to
reflect the current state of the github repository.
Reviewers: mehdi_amini, jyknight
Subscribers: jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58420
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@365645 91177308-0d34-0410-b5e6-96231b3b80d8
This adds documentation that describes remarks in LLVM.
It aims at explaining what remarks are, how to enable them, and what
users can do with the different modes.
It lists all the available flags in LLVM (excluding clang), and
describes the expected YAML structure as well as the tools that support
the YAML format today.
Differential Revision: https://reviews.llvm.org/D64355
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@365578 91177308-0d34-0410-b5e6-96231b3b80d8
Dump the DWARF information about call sites and call site parameters into
debug info sections.
The patch also provides an interface for the interpretation of instructions
that could load values of a call site parameters in order to generate DWARF
about the call site parameters.
([13/13] Introduce the debug entry values.)
Co-authored-by: Ananth Sowda <asowda@cisco.com>
Co-authored-by: Nikola Prica <nikola.prica@rt-rk.com>
Co-authored-by: Ivan Baev <ibaev@cisco.com>
Differential Revision: https://reviews.llvm.org/D60716
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@365467 91177308-0d34-0410-b5e6-96231b3b80d8
In particular, the --debug-syms switch really doesn't have anything to
do with debuggers, so I've updated the document accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@365461 91177308-0d34-0410-b5e6-96231b3b80d8
Some of the wording in the doc (taken largely from the help text), was a
little imprecise in some cases, so this patch makes it a little more
precise.
Reviewed by: JDevlieghere, probinson
Differential Revision: https://reviews.llvm.org/D64332
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@365451 91177308-0d34-0410-b5e6-96231b3b80d8
For background of BPF CO-RE project, please refer to
http://vger.kernel.org/bpfconf2019.html
In summary, BPF CO-RE intends to compile bpf programs
adjustable on struct/union layout change so the same
program can run on multiple kernels with adjustment
before loading based on native kernel structures.
In order to do this, we need keep track of GEP(getelementptr)
instruction base and result debuginfo types, so we
can adjust on the host based on kernel BTF info.
Capturing such information as an IR optimization is hard
as various optimization may have tweaked GEP and also
union is replaced by structure it is impossible to track
fieldindex for union member accesses.
Three intrinsic functions, preserve_{array,union,struct}_access_index,
are introducted.
addr = preserve_array_access_index(base, index, dimension)
addr = preserve_union_access_index(base, di_index)
addr = preserve_struct_access_index(base, gep_index, di_index)
here,
base: the base pointer for the array/union/struct access.
index: the last access index for array, the same for IR/DebugInfo layout.
dimension: the array dimension.
gep_index: the access index based on IR layout.
di_index: the access index based on user/debuginfo types.
For example, for the following example,
$ cat test.c
struct sk_buff {
int i;
int b1:1;
int b2:2;
union {
struct {
int o1;
int o2;
} o;
struct {
char flags;
char dev_id;
} dev;
int netid;
} u[10];
};
static int (*bpf_probe_read)(void *dst, int size, const void *unsafe_ptr)
= (void *) 4;
#define _(x) (__builtin_preserve_access_index(x))
int bpf_prog(struct sk_buff *ctx) {
char dev_id;
bpf_probe_read(&dev_id, sizeof(char), _(&ctx->u[5].dev.dev_id));
return dev_id;
}
$ clang -target bpf -O2 -g -emit-llvm -S -mllvm -print-before-all \
test.c >& log
The generated IR looks like below:
...
define dso_local i32 @bpf_prog(%struct.sk_buff*) #0 !dbg !15 {
%2 = alloca %struct.sk_buff*, align 8
%3 = alloca i8, align 1
store %struct.sk_buff* %0, %struct.sk_buff** %2, align 8, !tbaa !45
call void @llvm.dbg.declare(metadata %struct.sk_buff** %2, metadata !43, metadata !DIExpression()), !dbg !49
call void @llvm.lifetime.start.p0i8(i64 1, i8* %3) #4, !dbg !50
call void @llvm.dbg.declare(metadata i8* %3, metadata !44, metadata !DIExpression()), !dbg !51
%4 = load i32 (i8*, i32, i8*)*, i32 (i8*, i32, i8*)** @bpf_probe_read, align 8, !dbg !52, !tbaa !45
%5 = load %struct.sk_buff*, %struct.sk_buff** %2, align 8, !dbg !53, !tbaa !45
%6 = call [10 x %union.anon]* @llvm.preserve.struct.access.index.p0a10s_union.anons.p0s_struct.sk_buffs(
%struct.sk_buff* %5, i32 2, i32 3), !dbg !53, !llvm.preserve.access.index !19
%7 = call %union.anon* @llvm.preserve.array.access.index.p0s_union.anons.p0a10s_union.anons(
[10 x %union.anon]* %6, i32 1, i32 5), !dbg !53
%8 = call %union.anon* @llvm.preserve.union.access.index.p0s_union.anons.p0s_union.anons(
%union.anon* %7, i32 1), !dbg !53, !llvm.preserve.access.index !26
%9 = bitcast %union.anon* %8 to %struct.anon.0*, !dbg !53
%10 = call i8* @llvm.preserve.struct.access.index.p0i8.p0s_struct.anon.0s(
%struct.anon.0* %9, i32 1, i32 1), !dbg !53, !llvm.preserve.access.index !34
%11 = call i32 %4(i8* %3, i32 1, i8* %10), !dbg !52
%12 = load i8, i8* %3, align 1, !dbg !54, !tbaa !55
%13 = sext i8 %12 to i32, !dbg !54
call void @llvm.lifetime.end.p0i8(i64 1, i8* %3) #4, !dbg !56
ret i32 %13, !dbg !57
}
!19 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "sk_buff", file: !3, line: 1, size: 704, elements: !20)
!26 = distinct !DICompositeType(tag: DW_TAG_union_type, scope: !19, file: !3, line: 5, size: 64, elements: !27)
!34 = distinct !DICompositeType(tag: DW_TAG_structure_type, scope: !26, file: !3, line: 10, size: 16, elements: !35)
Note that @llvm.preserve.{struct,union}.access.index calls have metadata llvm.preserve.access.index
attached to instructions to provide struct/union debuginfo type information.
For &ctx->u[5].dev.dev_id,
. The "%6 = ..." represents struct member "u" with index 2 for IR layout and index 3 for DI layout.
. The "%7 = ..." represents array subscript "5".
. The "%8 = ..." represents union member "dev" with index 1 for DI layout.
. The "%10 = ..." represents struct member "dev_id" with index 1 for both IR and DI layout.
Basically, traversing the use-def chain recursively for the 3rd argument of bpf_probe_read() and
examining all preserve_*_access_index calls, the debuginfo struct/union/array access index
can be achieved.
The intrinsics also contain enough information to regenerate codes for IR layout.
For array and structure intrinsics, the proper GEP can be constructed.
For union intrinsics, replacing all uses of "addr" with "base" should be enough.
The test case ThinLTO/X86/lazyload_metadata.ll is adjusted to reflect the
new addition of the metadata.
Signed-off-by: Yonghong Song <yhs@fb.com>
Differential Revision: https://reviews.llvm.org/D61810
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@365423 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r365352.
Test ThinLTO/X86/lazyload_metadata.ll failed. Revert the commit
and at the same time to fix the issue.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@365360 91177308-0d34-0410-b5e6-96231b3b80d8
For background of BPF CO-RE project, please refer to
http://vger.kernel.org/bpfconf2019.html
In summary, BPF CO-RE intends to compile bpf programs
adjustable on struct/union layout change so the same
program can run on multiple kernels with adjustment
before loading based on native kernel structures.
In order to do this, we need keep track of GEP(getelementptr)
instruction base and result debuginfo types, so we
can adjust on the host based on kernel BTF info.
Capturing such information as an IR optimization is hard
as various optimization may have tweaked GEP and also
union is replaced by structure it is impossible to track
fieldindex for union member accesses.
Three intrinsic functions, preserve_{array,union,struct}_access_index,
are introducted.
addr = preserve_array_access_index(base, index, dimension)
addr = preserve_union_access_index(base, di_index)
addr = preserve_struct_access_index(base, gep_index, di_index)
here,
base: the base pointer for the array/union/struct access.
index: the last access index for array, the same for IR/DebugInfo layout.
dimension: the array dimension.
gep_index: the access index based on IR layout.
di_index: the access index based on user/debuginfo types.
For example, for the following example,
$ cat test.c
struct sk_buff {
int i;
int b1:1;
int b2:2;
union {
struct {
int o1;
int o2;
} o;
struct {
char flags;
char dev_id;
} dev;
int netid;
} u[10];
};
static int (*bpf_probe_read)(void *dst, int size, const void *unsafe_ptr)
= (void *) 4;
#define _(x) (__builtin_preserve_access_index(x))
int bpf_prog(struct sk_buff *ctx) {
char dev_id;
bpf_probe_read(&dev_id, sizeof(char), _(&ctx->u[5].dev.dev_id));
return dev_id;
}
$ clang -target bpf -O2 -g -emit-llvm -S -mllvm -print-before-all \
test.c >& log
The generated IR looks like below:
...
define dso_local i32 @bpf_prog(%struct.sk_buff*) #0 !dbg !15 {
%2 = alloca %struct.sk_buff*, align 8
%3 = alloca i8, align 1
store %struct.sk_buff* %0, %struct.sk_buff** %2, align 8, !tbaa !45
call void @llvm.dbg.declare(metadata %struct.sk_buff** %2, metadata !43, metadata !DIExpression()), !dbg !49
call void @llvm.lifetime.start.p0i8(i64 1, i8* %3) #4, !dbg !50
call void @llvm.dbg.declare(metadata i8* %3, metadata !44, metadata !DIExpression()), !dbg !51
%4 = load i32 (i8*, i32, i8*)*, i32 (i8*, i32, i8*)** @bpf_probe_read, align 8, !dbg !52, !tbaa !45
%5 = load %struct.sk_buff*, %struct.sk_buff** %2, align 8, !dbg !53, !tbaa !45
%6 = call [10 x %union.anon]* @llvm.preserve.struct.access.index.p0a10s_union.anons.p0s_struct.sk_buffs(
%struct.sk_buff* %5, i32 2, i32 3), !dbg !53, !llvm.preserve.access.index !19
%7 = call %union.anon* @llvm.preserve.array.access.index.p0s_union.anons.p0a10s_union.anons(
[10 x %union.anon]* %6, i32 1, i32 5), !dbg !53
%8 = call %union.anon* @llvm.preserve.union.access.index.p0s_union.anons.p0s_union.anons(
%union.anon* %7, i32 1), !dbg !53, !llvm.preserve.access.index !26
%9 = bitcast %union.anon* %8 to %struct.anon.0*, !dbg !53
%10 = call i8* @llvm.preserve.struct.access.index.p0i8.p0s_struct.anon.0s(
%struct.anon.0* %9, i32 1, i32 1), !dbg !53, !llvm.preserve.access.index !34
%11 = call i32 %4(i8* %3, i32 1, i8* %10), !dbg !52
%12 = load i8, i8* %3, align 1, !dbg !54, !tbaa !55
%13 = sext i8 %12 to i32, !dbg !54
call void @llvm.lifetime.end.p0i8(i64 1, i8* %3) #4, !dbg !56
ret i32 %13, !dbg !57
}
!19 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "sk_buff", file: !3, line: 1, size: 704, elements: !20)
!26 = distinct !DICompositeType(tag: DW_TAG_union_type, scope: !19, file: !3, line: 5, size: 64, elements: !27)
!34 = distinct !DICompositeType(tag: DW_TAG_structure_type, scope: !26, file: !3, line: 10, size: 16, elements: !35)
Note that @llvm.preserve.{struct,union}.access.index calls have metadata llvm.preserve.access.index
attached to instructions to provide struct/union debuginfo type information.
For &ctx->u[5].dev.dev_id,
. The "%6 = ..." represents struct member "u" with index 2 for IR layout and index 3 for DI layout.
. The "%7 = ..." represents array subscript "5".
. The "%8 = ..." represents union member "dev" with index 1 for DI layout.
. The "%10 = ..." represents struct member "dev_id" with index 1 for both IR and DI layout.
Basically, traversing the use-def chain recursively for the 3rd argument of bpf_probe_read() and
examining all preserve_*_access_index calls, the debuginfo struct/union/array access index
can be achieved.
The intrinsics also contain enough information to regenerate codes for IR layout.
For array and structure intrinsics, the proper GEP can be constructed.
For union intrinsics, replacing all uses of "addr" with "base" should be enough.
Signed-off-by: Yonghong Song <yhs@fb.com>
Differential Revision: https://reviews.llvm.org/D61810
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@365352 91177308-0d34-0410-b5e6-96231b3b80d8
Summary of changes:
- added description of GFX10;
- added description of operands sccz, vccz, lds_direct, etc;
- minor bugfixing and improvements.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@365347 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds a function attribute, nofree, to indicate that a function does
not, directly or indirectly, call a memory-deallocation function (e.g., free,
C++'s operator delete).
Reviewers: jdoerfert
Differential Revision: https://reviews.llvm.org/D49165
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@365336 91177308-0d34-0410-b5e6-96231b3b80d8
Similar to `FILECHECK_OPTS` for FileCheck, `LIT_OPTS` makes it easy to
adjust lit behavior when running the test suite via ninja. For
example:
```
$ LIT_OPTS='--time-tests -vv --filter=threadprivate' \
ninja check-clang-openmp
```
Reviewed By: probinson
Differential Revision: https://reviews.llvm.org/D64135
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@365313 91177308-0d34-0410-b5e6-96231b3b80d8
We briefly referred to being able to specify --target=binary without
explaining what binary input/output meant. This change adds a section on
this.
Reviewed by: MaskRay, abrachet
Differential Revision: https://reviews.llvm.org/D64245
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@365312 91177308-0d34-0410-b5e6-96231b3b80d8
Reintroduces the scalable vector IR type from D32530, after it was reverted
a couple of times due to increasing chromium LTO build times. This latest
incarnation removes the walk over aggregate types from the verifier entirely,
in favor of rejecting scalable vectors in the isValidElementType methods in
ArrayType and StructType. This removes the 70% degradation observed with
the second repro tarball from PR42210.
Reviewers: thakis, hans, rengolin, sdesmalen
Reviewed By: sdesmalen
Differential Revision: https://reviews.llvm.org/D64079
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@365203 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Changes "see also" links to use :manpage: instead of plain text or the form `name|name` which was being treated literally, not as a link.
Reviewers: jhenderson, rupprecht
Reviewed By: jhenderson
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63970
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@365159 91177308-0d34-0410-b5e6-96231b3b80d8
The --show-children option description describes what it does, and
references the =<offset> parameter of section dump switches. I don't
think it needs to be explained again in the documentation of the
section dump switches too.
Reviewed by: JDevlieghere
Differential Revision: https://reviews.llvm.org/D64132
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@365115 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Removed excess new lines from documentations. As far as I can tell, it seems as though restructured text is agnostic to new lines, the use of new lines was inconsistent and had no effect on how the files were being displayed.
Reviewers: jhenderson, rupprecht, JDevlieghere
Reviewed By: jhenderson
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63971
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@365105 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, the llvm-readelf documentation was essentially just a list
of differences to llvm-readobj. Since llvm-readelf is the more likely
goto tool for many people migrating to the LLVM toolchain, it seems like
it would be helpful to document all the switches in the llvm-readelf
document too. This change expands the options listed accordingly.
Additionally, they are unlikely to care what the differences are to
llvm-readobj, since they won't be familiar with the latter as there is
no GNU equivalent, so this change moves the "differences" section to
llvm-readobj's documentation.
Reviewed by: peter.smith
Differential Revision: https://reviews.llvm.org/D63826
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@364800 91177308-0d34-0410-b5e6-96231b3b80d8
Update the doc after llvm-svn: 364121 is landed.
With two more trivial fixes that are not related to
--disassemble-functions but still about llvm-objdump.
Reviewers: jhenderson, grimar, MaskRay, rupprecht, peter.smith
Reviewed by: jhenderson, MaskRay
Differential Revision: https://reviews.llvm.org/D63787
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@364573 91177308-0d34-0410-b5e6-96231b3b80d8
This patch introduces a new function attribute, willreturn, to indicate
that a call of this function will either exhibit undefined behavior or
comes back and continues execution at a point in the existing call stack
that includes the current invocation.
This attribute guarantees that the function does not have any endless
loops, endless recursion, or terminating functions like abort or exit.
Patch by Hideto Ueno (@uenoku)
Reviewers: jdoerfert
Subscribers: mehdi_amini, hiraditya, steven_wu, dexonsmith, lebedev.ri, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62801
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@364555 91177308-0d34-0410-b5e6-96231b3b80d8
The "See Also" section for llvm-nm didn't actually contain any links,
and the tools referred to didn't make much sense (referring to non-LLVM
tools, when we have equivalents, or tools that aren't really to do with
symbol dumping). llvm-objdump's didn't refer to llvm-readelf.
Reviewed by: grimar
Differential Revision: https://reviews.llvm.org/D63875
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@364552 91177308-0d34-0410-b5e6-96231b3b80d8
We saw a 70% ThinLTO link time increase in Chromium for Android, see
crbug.com/978817. Sounds like more of PR42210.
> Recommit of D32530 with a few small changes:
> - Stopped recursively walking through aggregates in
> the verifier, so that we don't impose too much
> overhead on large modules under LTO (see PR42210).
> - Changed tests to match; the errors are slightly
> different since they only report the array or
> struct that actually contains a scalable vector,
> rather than all aggregates which contain one in
> a nested member.
> - Corrected an older comment
>
> Reviewers: thakis, rengolin, sdesmalen
>
> Reviewed By: sdesmalen
>
> Differential Revision: https://reviews.llvm.org/D63321
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@364543 91177308-0d34-0410-b5e6-96231b3b80d8
Add the IR and the AsmPrinter parts for handling of the DW_OP_entry_values
DWARF operation.
([11/13] Introduce the debug entry values.)
Co-authored-by: Ananth Sowda <asowda@cisco.com>
Co-authored-by: Nikola Prica <nikola.prica@rt-rk.com>
Co-authored-by: Ivan Baev <ibaev@cisco.com>
Differential Revision: https://reviews.llvm.org/D60866
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@364542 91177308-0d34-0410-b5e6-96231b3b80d8
Sphinx allows for definitions of command-line options using
`.. option <name>` and references to those options via `:option:<name>`.
However, it looks like there is no scoping of these options by default,
meaning that links can end up pointing to incorrect documents. See for
example the llvm-mca document, which contains references to -o that,
prior to this patch, pointed to a different document. What's worse is
that these links appear to be non-deterministic in which one is picked
(on my machine, some references end up pointing to opt, whereas on the
live docs, they point to llvm-dwarfdump, for example).
The fix is to add the .. program <name> tag. This essentially namespaces
the options (definitions and references) to the named program, ensuring
that the links are kept correct.
Reviwed by: andreadb
Differential Revision: https://reviews.llvm.org/D63873
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@364538 91177308-0d34-0410-b5e6-96231b3b80d8
Add an attribute into the MachineFunction that tracks call site info.
([8/13] Introduce the debug entry values.)
Co-authored-by: Ananth Sowda <asowda@cisco.com>
Co-authored-by: Nikola Prica <nikola.prica@rt-rk.com>
Co-authored-by: Ivan Baev <ibaev@cisco.com>
Differential Revision: https://reviews.llvm.org/D61061
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@364506 91177308-0d34-0410-b5e6-96231b3b80d8
A unique DISubprogram may be attached to a function declaration used for
call site debug info.
([6/13] Introduce the debug entry values.)
Co-authored-by: Ananth Sowda <asowda@cisco.com>
Co-authored-by: Nikola Prica <nikola.prica@rt-rk.com>
Co-authored-by: Ivan Baev <ibaev@cisco.com>
Differential Revision: https://reviews.llvm.org/D60713
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@364500 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Implements direct and indirect tail calls enabled by the 'tail-call'
feature in both DAG ISel and FastISel. Updates existing call tests and
adds new tests including a binary encoding test.
Reviewers: aheejin
Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62877
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@364445 91177308-0d34-0410-b5e6-96231b3b80d8
As detailed in https://bugs.llvm.org/show_bug.cgi?id=42253, there were a
number of issues in the llvm-symbolizer documentation. This patch fixes
them by:
1. Adding [addresses...] to the synopsis, and matching the formatting
of other tools.
2. Rewriting the description to fix grammar issues and mention other
usage options.
3. Rewriting the examples to be easier to read.
4. Re-ordering the options into alphabetical order.
5. Improving the text of some of the option descriptions, and adding
some examples to individual options.
6. Splitting the Mach-O options into a separate section of the
document.
7. Standardizing on double dashes for long options throughout the file.
8. Adding a reference to the llvm-addr2line document.
Reviewed by: mtrent, ikudrin
Differential Revision: https://reviews.llvm.org/D63651
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@364410 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce the debug info flag that indicates that a parameter has unchanged
value throughout a function. This info will be used to emit the expressions
with DW_OP_entry_value.
([4/13] Introduce the debug entry values.)
Co-authored-by: Ananth Sowda <asowda@cisco.com>
Co-authored-by: Nikola Prica <nikola.prica@rt-rk.com>
Co-authored-by: Ivan Baev <ibaev@cisco.com>
Differential Revision: https://reviews.llvm.org/D58034
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@364406 91177308-0d34-0410-b5e6-96231b3b80d8
"To" selects an odd-numbered GPR, and "Te" an even one. There are some
8.1-M instructions that have one too few bits in their register fields
and require registers of particular parity, without necessarily using
a consecutive even/odd pair.
Also, the constraint letter "t" should select an MVE q-register, when
MVE is present. This didn't need any source changes, but some extra
tests have been added.
Reviewers: dmgreen, samparker, SjoerdMeijer
Subscribers: javed.absar, eraman, kristof.beyls, hiraditya, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D60709
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@364331 91177308-0d34-0410-b5e6-96231b3b80d8
There were a number of issues with the llvm-readobj documentation. The
following points were raised in https://bugs.llvm.org/show_bug.cgi?id=42255,
and have been fixed in this patch:
1. The description section claimed "The tool and its output is
primarily designed for use in FileCheck-based tests" which is not
really the case any more.
2. The documentation used single-dash long options for option names,
but references in the help text to other options exclusively used
double-dashes. Fixed by standardising on double-dashes for all
long-form options.
3. The majority of options available and in the help text were not
present in the documentation. This patch adds them.
4. Several aliases, both long and short, were missing, e.g. --relocs.
Additionally, this patch improves the documentation by:
1. Splitting the options into categories based on the file format they
are specific to.
2. Updating the Exit Status section to correctly mention that errors
lead to a non-zero exit code.
3. Adding a See Also section referencing other similar LLVM tools.
4. Improving/correcting some of the descriptions of options that did
not quite match up with what llvm-readobj does.
Reviewed by: peter.smith, MaskRay, mtrent
Differential Revision: https://reviews.llvm.org/D63719
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@364306 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The directive defines a symbol as an group/local memory (LDS) symbol.
LDS symbols behave similar to common symbols for the purposes of ELF,
using the processor-specific SHN_AMDGPU_LDS as section index.
It is the linker and/or runtime loader's job to "instantiate" LDS symbols
and resolve relocations that reference them.
It is not possible to initialize LDS memory (not even zero-initialize
as for .bss).
We want to be able to link together objects -- starting with relocatable
objects, but possible expanding to shared objects in the future -- that
access LDS memory in a flexible way.
LDS memory is in an address space that is entirely separate from the
address space that contains the program image (code and normal data),
so having program segments for it doesn't really make sense.
Furthermore, we want to be able to compile multiple kernels in a
compilation unit which have disjoint use of LDS memory. In that case,
we may want to place LDS symbols differently for different kernels
to save memory (LDS memory is very limited and physically private to
each kernel invocation), so we can't simply place LDS symbols in a
.lds section.
Hence this solution where LDS symbols always stay undefined.
Change-Id: I08cbc37a7c0c32f53f7b6123aa0afc91dbc1748f
Reviewers: arsenm, rampitec, t-tye, b-sumner, jsjodin
Subscribers: kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, rupprecht, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61493
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@364296 91177308-0d34-0410-b5e6-96231b3b80d8
Many LLVM-based tools already support response files (i.e. files
containing a list of options, specified with '@'). This change simply
updates the documentation and help text for some of these tools to
include it. I haven't attempted to fix all tools, just a selection that
I am interested in.
I've taken the opportunity to add some tests for --help behaviour, where
they were missing. We could expand these tests, but I don't think that's
within scope of this patch.
This fixes https://bugs.llvm.org/show_bug.cgi?id=42233 and
https://bugs.llvm.org/show_bug.cgi?id=42236.
Reviewed by: grimar, MaskRay, jkorous
Differential Revision: https://reviews.llvm.org/D63597
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@364036 91177308-0d34-0410-b5e6-96231b3b80d8
The llvm-objdump document was missing many options, and there were also
some style issues with it. This patches fixes all but the first issue
listed in https://bugs.llvm.org/show_bug.cgi?id=42249 by:
1. Adding missing options and commands.
2. Standardising on double dashes for long-options throughout.
3. Moving Mach-O specific options to a separate section.
4. Removing options that don't exist or aren't relevant to
llvm-objdump.
Reviewed by: MaskRay, mtrent, alexshap
Differential Revision: https://reviews.llvm.org/D63606
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@364019 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Stop referring to "numeric expression", using simply the term
"expression" instead. Likewise for numeric operation since operations
are only used in numeric expressions.
Reviewers: jhenderson, jdenny, probinson, arichardson
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63500
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363901 91177308-0d34-0410-b5e6-96231b3b80d8
Recommit of D32530 with a few small changes:
- Stopped recursively walking through aggregates in
the verifier, so that we don't impose too much
overhead on large modules under LTO (see PR42210).
- Changed tests to match; the errors are slightly
different since they only report the array or
struct that actually contains a scalable vector,
rather than all aggregates which contain one in
a nested member.
- Corrected an older comment
Reviewers: thakis, rengolin, sdesmalen
Reviewed By: sdesmalen
Differential Revision: https://reviews.llvm.org/D63321
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363658 91177308-0d34-0410-b5e6-96231b3b80d8
This patch documents that LLVM does not describe all changes in variable
locations during the prologue and the epilogue. The debugger doesn't /
shouldn't step through that portion of the function anyway, and describing
every location through such stages would bloat location lists.
Perform some minor cleanup at the same time,
* Fix an enumerated list
* Document that dbg.declare intrinsics have their variable location recorded
in a MachineFunction table, not with DBG_VALUE meta-insts
* Adds frame-indexes to the list of things that can be operands to
DBG_VALUEs.
Differential Revision: https://reviews.llvm.org/D63083
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363654 91177308-0d34-0410-b5e6-96231b3b80d8
The goal is to improve hwasan's error reporting for stack use-after-return by
recording enough information to allow the specific variable that was accessed
to be identified based on the pointer's tag. Currently we record the PC and
lower bits of SP for each stack frame we create (which will eventually be
enough to derive the base tag used by the stack frame) but that's not enough
to determine the specific tag for each variable, which is the stack frame's
base tag XOR a value (the "tag offset") that is unique for each variable in
a function.
In IR, the tag offset is most naturally represented as part of a location
expression on the llvm.dbg.declare instruction. However, the presence of the
tag offset in the variable's actual location expression is likely to confuse
debuggers which won't know about tag offsets, and moreover the tag offset
is not required for a debugger to determine the location of the variable on
the stack, so at the DWARF level it is represented as an attribute so that
it will be ignored by debuggers that don't know about it.
Differential Revision: https://reviews.llvm.org/D63119
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363635 91177308-0d34-0410-b5e6-96231b3b80d8
The docs and help text for --show-parents and --show-children were a bit
inconsistent. The help text claimed they had an effect when "=<offset>"
was used, whereas the doc said it had an effect when "--find" or
"--name" were used. This change changes the doc to mention "=<offset>"
and removes this reference from the help text, to avoid having a very
long description in the help text (it still says "when selectively
printing entries").
Reviewed by: JDevlieghere, aprantl
Differential Revision: https://reviews.llvm.org/D63275
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363380 91177308-0d34-0410-b5e6-96231b3b80d8
I find the current documentation of poison somewhat confusing,
mainly because its use of "undefined behavior" doesn't seem to
align with our usual interpretation (of immediate UB). Especially
the sentence "any instruction that has a dependence on a poison
value has undefined behavior" is very confusing.
Clarify poison semantics by:
* Replacing the introductory paragraph with the standard rationale
for having poison values.
* Spelling out that instructions depending on poison return poison.
* Spelling out how we go from a poison value to immediate undefined
behavior and give the two examples we currently use in ValueTracking.
* Spelling out that side effects depending on poison are UB.
Differential Revision: https://reviews.llvm.org/D63044
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363320 91177308-0d34-0410-b5e6-96231b3b80d8
This patch uses the mechanism from D62995 to strengthen the
definitions of the reduction intrinsics by letting the scalar
result/accumulator type be overloaded from the vector element type.
For example:
; The LLVM LangRef specifies that the scalar result must equal the
; vector element type, but this is not checked/enforced by LLVM.
declare i32 @llvm.experimental.vector.reduce.or.i32.v4i32(<4 x i32> %a)
This patch changes that into:
declare i32 @llvm.experimental.vector.reduce.or.v4i32(<4 x i32> %a)
Which has the type-constraint more explicit and causes LLVM to check
the result type with the vector element type.
Reviewers: RKSimon, arsenm, rnk, greened, aemerson
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D62996
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363240 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: In this patch, I updated `load` instruction syntax and fixed function definition. Besides, I re-named some variables to make them obey SSA rule.
Reviewers: MaskRay
Reviewed By: MaskRay
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63186
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363142 91177308-0d34-0410-b5e6-96231b3b80d8
The --print-size help text and documentation claimed that the size was
printed instead of the address, but this is incorrect. It is printed as
well as the address. This patch fixes this issue.
Reviewed by: MaskRay, mtrent, ruiu
Differential Revision: https://reviews.llvm.org/D63142
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363136 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This splits out a section in the command guide for llvm tools that can be used as replacements for GNU tools. For pages that didn't exist, I added stub pages that can be individually filled in by followup patches.
Tested by running `ninja docs-llvm-html` and inspecting locally.
Reviewers: jhenderson, MaskRay, grimar, alexshap
Reviewed By: jhenderson, MaskRay, grimar
Subscribers: smeenai, arphaman, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63014
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363100 91177308-0d34-0410-b5e6-96231b3b80d8
Replacing '.. code-block:: llvm' by '::' is a quick fix to the
build warning/error: Could not lex literal_block as "llvm".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363079 91177308-0d34-0410-b5e6-96231b3b80d8
There was a typo in the --ignore-case help text that was copied into the
llvm-dwarfdump command-guide. Additionally, this patch simplifies the
wording, since it was unnecessarily verbose: the switch applies for
searching in general and doesn't need explicitly stating different
search modes (which might go out-of-date as options are added or
removed).
Reviwed by: JDevlieghere
Differential Revision: https://reviews.llvm.org/D63133
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363066 91177308-0d34-0410-b5e6-96231b3b80d8
-o is in the documentation, but not in the llvm-dwarfdump help text.
This patch adds it by inverting the -o and --out-file aliasing. It also
removes --out-file from the documentation, since we don't really want
people to be using this switch in practice.
Reviewed by: aprantl, JDevlieghere, dblaikie
Differential Revision: https://reviews.llvm.org/D63013
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363044 91177308-0d34-0410-b5e6-96231b3b80d8
This patch changes how LLVM handles the accumulator/start value
in the reduction, by never ignoring it regardless of the presence of
fast-math flags on callsites. This change introduces the following
new intrinsics to replace the existing ones:
llvm.experimental.vector.reduce.fadd -> llvm.experimental.vector.reduce.v2.fadd
llvm.experimental.vector.reduce.fmul -> llvm.experimental.vector.reduce.v2.fmul
and adds functionality to auto-upgrade existing LLVM IR and bitcode.
Reviewers: RKSimon, greened, dmgreen, nikic, simoll, aemerson
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D60261
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363035 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit f4fc01f8dd3a5dfd2060d1ad0df6b90e8351ddf7.
It caused a 3-4x slowdown when doing thinlto links, PR42210.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@362913 91177308-0d34-0410-b5e6-96231b3b80d8
On the Command Guide page, there are multiple sections with links to the
different documentation pages available for LLVM tools. The "Basic
Tools" section includes tools like llvm-objdump, llvm-nm and so on. The
"Developer Tools" section contains things like FileCheck and lit. This
change moves llvm-readobj into the former block, from the latter.
Reviewed by: MaskRay
Differential Revision: https://reviews.llvm.org/D63011
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@362813 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch is part of a patch series to add support for FileCheck
numeric expressions. This specific patch introduces support for defining
numeric variable in a CHECK directive.
This commit introduces support for defining numeric variable from a
litteral value in the input text. Numeric expressions can then use the
variable provided it is on a later line.
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/D60386
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@362705 91177308-0d34-0410-b5e6-96231b3b80d8
When we switch to opaque pointer types we will need some way to describe
how many bytes a 'byval' parameter should occupy on the stack. This adds
a (for now) optional extra type parameter.
If present, the type must match the pointee type of the argument.
The original commit did not remap byval types when linking modules, which broke
LTO. This version fixes that.
Note to front-end maintainers: if this causes test failures, it's probably
because the "byval" attribute is printed after attributes without any parameter
after this change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@362128 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This updates all places in documentation that refer to "Mac OS X", "OS X", etc.
to instead use the modern name "macOS" when no specific version number is
mentioned.
If a specific version is mentioned, this attempts to use the OS name at the time
of that version:
* Mac OS X for 10.0 - 10.7
* OS X for 10.8 - 10.11
* macOS for 10.12 - present
Reviewers: JDevlieghere
Subscribers: mgorny, christof, arphaman, cfe-commits, lldb-commits, libcxx-commits, llvm-commits
Tags: #clang, #lldb, #libc, #llvm
Differential Revision: https://reviews.llvm.org/D62654
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@362113 91177308-0d34-0410-b5e6-96231b3b80d8
When we switch to opaque pointer types we will need some way to describe
how many bytes a 'byval' parameter should occupy on the stack. This adds
a (for now) optional extra type parameter.
If present, the type must match the pointee type of the argument.
Note to front-end maintainers: if this causes test failures, it's probably
because the "byval" attribute is printed after attributes without any parameter
after this change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@362012 91177308-0d34-0410-b5e6-96231b3b80d8
* Adds a 'scalable' flag to VectorType
* Adds an 'ElementCount' class to VectorType to pass (possibly scalable) vector lengths, with overloaded operators.
* Modifies existing helper functions to use ElementCount
* Adds support for serializing/deserializing to/from both textual and bitcode IR formats
* Extends the verifier to reject global variables of scalable types
* Updates documentation
See the latest version of the RFC here: http://lists.llvm.org/pipermail/llvm-dev/2018-July/124396.html
Reviewers: rengolin, lattner, echristo, chandlerc, hfinkel, rkruppe, samparker, SjoerdMeijer, greened, sebpop
Reviewed By: hfinkel, sebpop
Differential Revision: https://reviews.llvm.org/D32530
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@361953 91177308-0d34-0410-b5e6-96231b3b80d8
This patch add the ISD::LRINT and ISD::LLRINT along with new
intrinsics. The changes are straightforward as for other
floating-point rounding functions, with just some adjustments
required to handle the return value being an interger.
The idea is to optimize lrint/llrint generation for AArch64
in a subsequent patch. Current semantic is just route it to libm
symbol.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D62017
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@361875 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Terminology introduced by [[#]] blocks is confusing and does not
integrate well with existing terminology.
First, variables referred by [[]] blocks are called "pattern variables"
while the text a CHECK directive needs to match is called a "CHECK
pattern". This is inconsistent with variables in [[#]] blocks since
[[#]] blocks are also found in CHECK pattern yet those variables are
called "numeric variable".
Second, the replacing of both [[]] and [[#]] blocks by the value of the
variable or expression they contain is represented by a
FileCheckPatternSubstitution class. The naming refers to being a
substitution in a CHECK pattern but could be wrongly understood as being
a substitution of a pattern variable.
Third and lastly, comments use "numeric expression" to refer both to the
[[#]] blocks as well as to the numeric expressions these blocks contain
which get evaluated at match time.
This patch solves these confusions by
- calling variables in [[]] and [[#]] blocks as string and numeric
variables respectively;
- referring to [[]] and [[#]] as substitution *blocks*, with the former
being a string substitution block and the latter a numeric
substitution block;
- calling [[]] and [[#]] blocks to be replaced by the value of a
variable or expression they contain a substitution (as opposed to
definition when these blocks are used to defined a variable), with the
former being a string substitution and the latter a numeric
substitution;
- renaming the FileCheckPatternSubstitution as a FileCheckSubstitution
class with FileCheckStringSubstitution and
FileCheckNumericSubstitution subclasses;
- restricting the use of "numeric expression" to refer to the expression
that is evaluated in a numeric substitution.
While numeric substitution blocks only support numeric substitutions of
numeric expressions at the moment there are plans to augment numeric
substitution blocks to support numeric definitions as well as both a
numeric definition and numeric substitution in the same numeric
substitution block.
Reviewers: jhenderson, jdenny, probinson, arichardson
Subscribers: hiraditya, arichardson, probinson, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62146
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@361445 91177308-0d34-0410-b5e6-96231b3b80d8
This is a minimal start to correcting a problem most directly discussed in PR38086:
https://bugs.llvm.org/show_bug.cgi?id=38086
We have been hacking around a limitation for FP select patterns by using the
fast-math-flags on the condition of the select rather than the select itself.
This patch just allows FMF to appear with the 'select' opcode. No changes are
needed to "FPMathOperator" because it already includes select-of-FP because
that definition is based on the (return) value type.
Once we have this ability, we can start correcting and adding IR transforms
to use the FMF on a 'select' instruction. The instcombine and vectorizer test
diffs only show that the IRBuilder change is behaving as expected by applying
an FMF guard value to 'select'.
For reference:
rL241901 - allowed FMF with fcmp
rL255555 - allowed FMF with FP calls
Differential Revision: https://reviews.llvm.org/D61917
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@361401 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
When building Doxygen docs for llvm and clang, it helpfully prints a warning at
the end noting that the `LOOKUP_CACHE_SIZE` value was too small to keep all
symbols in memory.
By increasing to the size it recommends, Doxygen builds have greatly improved
performance. On my machine, time to run `doxygen-llvm` changes from 34 minutes
to 22 minutes, which is a decent amount of time saved by changing a single
number.
Reviewed By: hintonda
Patch by J. Ryan Stinnett!
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D62138
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@361343 91177308-0d34-0410-b5e6-96231b3b80d8
This should be a valid exception to the general rule of not creating new shuffle masks in IR...
because we already do it. :)
Also, DAG combining/legalization will undo this by widening the shuffle back out if needed.
Explanation for how we already do this: SLP or vector source can create chains of insert/extract
as shown in 1 of the examples from PR16739:
https://godbolt.org/z/NlK7rAhttps://bugs.llvm.org/show_bug.cgi?id=16739
And we expect instcombine or DAGCombine to clean that up by creating relatively simple shuffles.
Differential Revision: https://reviews.llvm.org/D62024
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@361338 91177308-0d34-0410-b5e6-96231b3b80d8
Add an intrinsic that takes 2 signed integers with the scale of them provided
as the third argument and performs fixed point multiplication on them. The
result is saturated and clamped between the largest and smallest representable
values of the first 2 operands.
This is a part of implementing fixed point arithmetic in clang where some of
the more complex operations will be implemented as intrinsics.
Differential Revision: https://reviews.llvm.org/D55720
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@361289 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This document is an attempt to provide a guide for best practices for using the LLVM build system to generate distributable LLVM-based tools.
Most of the document is geared toward distributions of LLVM-based toolchains, but much of it also applies to distributing other LLVM-based tools and libraries.
Reviewers: tstellar, phosek, jroelofs, hans, sylvestre.ledru
Reviewed By: tstellar
Subscribers: smeenai, dschuff, arphaman, winksaville, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62040
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@361272 91177308-0d34-0410-b5e6-96231b3b80d8
We shouldn't really make assumptions about possible sizes for long and long long. And longer term we should probably support vectorizing these intrinsics. By making the result types not fixed we can support vectors as well.
Differential Revision: https://reviews.llvm.org/D62026
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@361169 91177308-0d34-0410-b5e6-96231b3b80d8
The scalar start/accumulator value of the fadd- and fmul reduction
should match the result type of the reduction, as well as the vector
element-type of the input vector. Although this was not explicitly
specified in the LangRef, it was taken for granted in code implementing
the reductions. The patch also fixes the LangRef by adding this
constraint.
Reviewed By: aemerson, nikic
Differential Revision: https://reviews.llvm.org/D60260
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@361133 91177308-0d34-0410-b5e6-96231b3b80d8
This patch implements a limited form of autolinking primarily designed to allow
either the --dependent-library compiler option, or "comment lib" pragmas (
https://docs.microsoft.com/en-us/cpp/preprocessor/comment-c-cpp?view=vs-2017) in
C/C++ e.g. #pragma comment(lib, "foo"), to cause an ELF linker to automatically
add the specified library to the link when processing the input file generated
by the compiler.
Currently this extension is unique to LLVM and LLD. However, care has been taken
to design this feature so that it could be supported by other ELF linkers.
The design goals were to provide:
- A simple linking model for developers to reason about.
- The ability to to override autolinking from the linker command line.
- Source code compatibility, where possible, with "comment lib" pragmas in other
environments (MSVC in particular).
Dependent library support is implemented differently for ELF platforms than on
the other platforms. Primarily this difference is that on ELF we pass the
dependent library specifiers directly to the linker without manipulating them.
This is in contrast to other platforms where they are mapped to a specific
linker option by the compiler. This difference is a result of the greater
variety of ELF linkers and the fact that ELF linkers tend to handle libraries in
a more complicated fashion than on other platforms. This forces us to defer
handling the specifiers to the linker.
In order to achieve a level of source code compatibility with other platforms
we have restricted this feature to work with libraries that meet the following
"reasonable" requirements:
1. There are no competing defined symbols in a given set of libraries, or
if they exist, the program owner doesn't care which is linked to their
program.
2. There may be circular dependencies between libraries.
The binary representation is a mergeable string section (SHF_MERGE,
SHF_STRINGS), called .deplibs, with custom type SHT_LLVM_DEPENDENT_LIBRARIES
(0x6fff4c04). The compiler forms this section by concatenating the arguments of
the "comment lib" pragmas and --dependent-library options in the order they are
encountered. Partial (-r, -Ur) links are handled by concatenating .deplibs
sections with the normal mergeable string section rules. As an example, #pragma
comment(lib, "foo") would result in:
.section ".deplibs","MS",@llvm_dependent_libraries,1
.asciz "foo"
For LTO, equivalent information to the contents of a the .deplibs section can be
retrieved by the LLD for bitcode input files.
LLD processes the dependent library specifiers in the following way:
1. Dependent libraries which are found from the specifiers in .deplibs sections
of relocatable object files are added when the linker decides to include that
file (which could itself be in a library) in the link. Dependent libraries
behave as if they were appended to the command line after all other options. As
a consequence the set of dependent libraries are searched last to resolve
symbols.
2. It is an error if a file cannot be found for a given specifier.
3. Any command line options in effect at the end of the command line parsing apply
to the dependent libraries, e.g. --whole-archive.
4. The linker tries to add a library or relocatable object file from each of the
strings in a .deplibs section by; first, handling the string as if it was
specified on the command line; second, by looking for the string in each of the
library search paths in turn; third, by looking for a lib<string>.a or
lib<string>.so (depending on the current mode of the linker) in each of the
library search paths.
5. A new command line option --no-dependent-libraries tells LLD to ignore the
dependent libraries.
Rationale for the above points:
1. Adding the dependent libraries last makes the process simple to understand
from a developers perspective. All linkers are able to implement this scheme.
2. Error-ing for libraries that are not found seems like better behavior than
failing the link during symbol resolution.
3. It seems useful for the user to be able to apply command line options which
will affect all of the dependent libraries. There is a potential problem of
surprise for developers, who might not realize that these options would apply
to these "invisible" input files; however, despite the potential for surprise,
this is easy for developers to reason about and gives developers the control
that they may require.
4. This algorithm takes into account all of the different ways that ELF linkers
find input files. The different search methods are tried by the linker in most
obvious to least obvious order.
5. I considered adding finer grained control over which dependent libraries were
ignored (e.g. MSVC has /nodefaultlib:<library>); however, I concluded that this
is not necessary: if finer control is required developers can fall back to using
the command line directly.
RFC thread: http://lists.llvm.org/pipermail/llvm-dev/2019-March/131004.html.
Differential Revision: https://reviews.llvm.org/D60274
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360984 91177308-0d34-0410-b5e6-96231b3b80d8
This patch add the ISD::LROUND and ISD::LLROUND along with new
intrinsics. The changes are straightforward as for other
floating-point rounding functions, with just some adjustments
required to handle the return value being an interger.
The idea is to optimize lround/llround generation for AArch64
in a subsequent patch. Current semantic is just route it to libm
symbol.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360889 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Change example of input text from being llvm block to being gas block
since that text is made-up assembly.
Reviewers: jhenderson, jdenny, probinson, arichardson
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61893
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360781 91177308-0d34-0410-b5e6-96231b3b80d8
The 3-field form was introduced by D3499 in 2014 and the legacy 2-field
form was planned to be removed in LLVM 4.0
For the textual format, this patch migrates the existing 2-field form to
use the 3-field form and deletes the compatibility code.
test/Verifier/global-ctors-2.ll checks we have a friendly error message.
For bitcode, lib/IR/AutoUpgrade UpgradeGlobalVariables will upgrade the
2-field form (add i8* null as the third field).
Reviewed By: rnk, dexonsmith
Differential Revision: https://reviews.llvm.org/D61547
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360742 91177308-0d34-0410-b5e6-96231b3b80d8
This reinstates r360578 (git e47362c1ec1ea31b626336cc05822035601c3e57),
reverted in r360653 (git 004393681c25e34e921adccc69ae6378090dee54),
with a fix for the list added in FileCheck.rst to build without error.
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/D60385
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360665 91177308-0d34-0410-b5e6-96231b3b80d8
The new fptrunc and fpext intrinsics are constrained versions of the
regular fptrunc and fpext instructions.
Reviewed by: Andrew Kaylor, Craig Topper, Cameron McInally, Conner Abbot
Approved by: Craig Topper
Differential Revision: https://reviews.llvm.org/D55897
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360581 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch is part of a patch series to add support for FileCheck
numeric expressions. This specific patch introduces regular numeric
variables which can be set on the command-line.
This commit introduces regular numeric variable that can be set on the
command-line with the -D option to a numeric value. They can then be
used in CHECK patterns in numeric expression with the same shape as
@LINE numeric expression, ie. VAR, VAR+offset or VAR-offset where offset
is an integer literal.
The commit also enable strict whitespace in the verbose.txt testcase to
check that the position or the location diagnostics. It fixes one of the
existing CHECK in the process which was not accurately testing a
location diagnostic (ie. the diagnostic was correct, not the CHECK).
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/D60385
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360578 91177308-0d34-0410-b5e6-96231b3b80d8
This patch fixes PR41523
https://bugs.llvm.org/show_bug.cgi?id=41523
Regions can now nest/overlap provided that they have different names.
Anonymous regions cannot overlap.
Region end markers must specify the region name. The only exception is for when
there is only one user-defined region; in that particular case, the region end
marker doesn't need to specify a name.
Incorrect region end markers are no longer ignored. Instead, the tool reports an
error and we exit with an error code.
Added test cases to verify the new diagnostic error messages.
Updated the llvm-mca docs to reflect this feature change.
Differential Revision: https://reviews.llvm.org/D61676
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360351 91177308-0d34-0410-b5e6-96231b3b80d8
Fix the values of BPF_X and BPF_K according to BPFInstrFormats.td:
"
def BPF_K : BPFSrcType<0x0>;
def BPF_X : BPFSrcType<0x1>;
"
The right value for BPF_X is 0x1, and the right value for BPF_K is 0x0.
Signed-off-by: Wang YanQing <udknight@gmail.com>
Differential Revision: https://reviews.llvm.org/D61512
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@359904 91177308-0d34-0410-b5e6-96231b3b80d8
The unwind tables (`.eh_frame`, `.arm.extab`) add a significant chunk of data to
the final binaries. These should not be needed normally, particularly when
exceptions are disabled. This enables shrinking `lldb-server` by ~18% (3 MiB)
when built with gold.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@359819 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch is part of a patch series to add support for FileCheck
numeric expressions. This specific patch introduces the @LINE numeric
expressions.
This commit introduces a new syntax to express a relation a numeric
value in the input text must have with the line number of a given CHECK
pattern: [[#<@LINE numeric expression>]]. Further commits build on that
to express relations between several numeric values in the input text.
To help with naming, regular variables are renamed into pattern
variables and old @LINE expression syntax is referred to as legacy
numeric expression.
Compared to existing @LINE expressions, this new syntax allow arbitrary
spacing between the component of the expression. It offers otherwise the
same functionality but the commit serves to introduce some of the data
structure needed to support more general numeric expressions.
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/D60384
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@359741 91177308-0d34-0410-b5e6-96231b3b80d8
The now-correctly-referenced label dbi_type_server_map_substream didn't
exist. Rewrite things a bit after looking at NewDBIHdr in dbi.h and its
use in dbi.cpp in the reference implementation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@359721 91177308-0d34-0410-b5e6-96231b3b80d8
- Fix a broken link
- Some spelling fixes
- Remove an unnecessary "amortized"
- Don't say "log(n) random access"; "random access" means O(1)
- Make MSF overview a bit more concise
Differential Revision: https://reviews.llvm.org/D61196
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@359714 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
* The getActionDefinitionsBuilder() is now documented.
* Includes descriptions of the various actions (legal*, widenScalar*, lower*,
etc).
* Includes descriptions of the various predicates (*If, *For,
*ForCartesianProduct, etc.)
* Includes the rule-order details
* Removed the out-of-date prohibition on non-power-of-2 types.
* Removed the Vector types section since it was incorrect and vectors follow the
same ruleset as scalars. They're only special in the sense that more of the
actions and predicates are meaningful for them (e.g. moreElements).
* Clarified the position on context sensitive legality (which is not permitted)
and contrasted this with context sensitive legalization (which is permitted).
Reviewers: bogner, aditya_nandakumar, volkan, aemerson, paquette, arsenm
Reviewed By: paquette
Subscribers: wdng, rovka, kristof.beyls, jfb, Petar.Avramovic, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61273
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@359705 91177308-0d34-0410-b5e6-96231b3b80d8
We use both -long-option and --long-option in tests. Switch to --long-option for consistency.
In the "llvm-readelf" mode, -long-option is discouraged as it conflicts with grouped short options and it is not accepted by GNU readelf.
While updating the tests, change llvm-readobj -s to llvm-readobj -S to reduce confusion ("s" is --section-headers in llvm-readobj but --symbols in llvm-readelf).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@359649 91177308-0d34-0410-b5e6-96231b3b80d8
* Add support for uniquing strings in the remark streamer and emitting the string table in the remarks section.
* Add parsing support for the string table in the RemarkParser.
From this remark:
```
--- !Missed
Pass: inline
Name: NoDefinition
DebugLoc: { File: 'test-suite/SingleSource/UnitTests/2002-04-17-PrintfChar.c',
Line: 7, Column: 3 }
Function: printArgsNoRet
Args:
- Callee: printf
- String: ' will not be inlined into '
- Caller: printArgsNoRet
DebugLoc: { File: 'test-suite/SingleSource/UnitTests/2002-04-17-PrintfChar.c',
Line: 6, Column: 0 }
- String: ' because its definition is unavailable'
...
```
to:
```
--- !Missed
Pass: 0
Name: 1
DebugLoc: { File: 3, Line: 7, Column: 3 }
Function: 2
Args:
- Callee: 4
- String: 5
- Caller: 2
DebugLoc: { File: 3, Line: 6, Column: 0 }
- String: 6
...
```
And the string table in the .remarks/__remarks section containing:
```
inline\0NoDefinition\0printArgsNoRet\0
test-suite/SingleSource/UnitTests/2002-04-17-PrintfChar.c\0printf\0
will not be inlined into \0 because its definition is unavailable\0
```
This is mostly supposed to be used for testing purposes, but it gives us
a 2x reduction in the remark size, and is an incremental change for the
updates to the remarks file format.
Differential Revision: https://reviews.llvm.org/D60227
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@359050 91177308-0d34-0410-b5e6-96231b3b80d8
This adds an alias for llvm-symbolizer with different defaults so that
it can be used as a drop-in replacement for GNU's addr2line.
If a substring "addr2line" is found in the tool's name:
* it defaults "-i", "-f" and "-C" to OFF;
* it uses "--output-style=GNU" by default.
Differential Revision: https://reviews.llvm.org/D60067
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358749 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Add DefaultOption flag to CommandLineParser which provides a
default option or alias, but allows users to override it for some
other purpose as needed.
Also, add `-h` as a default alias to `-help`, which can be seamlessly
overridden by applications like llvm-objdump and llvm-readobj which
use `-h` as an alias for other options.
(relanding after revert, r358414)
Added DefaultOptions.clear() to reset().
Reviewers: alexfh, klimek
Reviewed By: klimek
Subscribers: kristina, MaskRay, mehdi_amini, inglorion, dexonsmith, hiraditya, llvm-commits, jhenderson, arphaman, cfe-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D59746
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358428 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds documentation explaining how variable location information is
compiled from the IR representation down to the end of the codegen pipeline,
but avoiding discussion of file formats and encoding.
This should make it clearer how the dbg.value / dbg.declare etc intrinsics
are transformed and arranged into DBG_VALUE instructions, and their meaning.
Differential Revision: https://reviews.llvm.org/D59790
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358385 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Add DefaultOption flag to CommandLineParser which provides a
default option or alias, but allows users to override it for some
other purpose as needed.
Also, add `-h` as a default alias to `-help`, which can be seamlessly
overridden by applications like llvm-objdump and llvm-readobj which
use `-h` as an alias for other options.
Reviewers: alexfh, klimek
Reviewed By: klimek
Subscribers: MaskRay, mehdi_amini, inglorion, dexonsmith, hiraditya, llvm-commits, jhenderson, arphaman, cfe-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D59746
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358337 91177308-0d34-0410-b5e6-96231b3b80d8
In tutorial "8. Kaleidoscope: Compiling to Object Code" a call to
TargetMachine->addPassesToEmitFile(pass, dest, FileType) is missing
nullptr as its 3rd value.
Patch by Sajjad Heydari!
Differential revision: https://reviews.llvm.org/D60369
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358267 91177308-0d34-0410-b5e6-96231b3b80d8
This puts the general layout of the document in place and fully
describes 1 simple type record. Followups will fill out more
pieces.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358119 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
```
``!listsplat(a, size)``
A list value that contains the value ``a`` ``size`` times.
Example: ``!listsplat(0, 2)`` results in ``[0, 0]``.
```
I plan to use this in X86ScheduleBdVer2.td for LoadRes handling.
This is a little bit controversial because unlike every other binary operator
the types aren't identical.
Reviewers: stoklund, javed.absar, nhaehnle, craig.topper
Reviewed By: javed.absar
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60367
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358117 91177308-0d34-0410-b5e6-96231b3b80d8
It makes more sense to print out the number of micro opcodes that are issued
every cycle rather than the number of instructions issued per cycle.
This behavior is also consistent with the dispatch-stats: numbers from the two
views can now be easily compared.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@357919 91177308-0d34-0410-b5e6-96231b3b80d8
Simplify building with particular C++ standards by replacing the
specific "enable standard X" flags with a flag that allows specifying
the standard you want directly.
We preserve compatibility with the existing flags so that anyone with
those flags in existing caches won't break mysteriously.
Differential Revision: https://reviews.llvm.org/D60399
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@357899 91177308-0d34-0410-b5e6-96231b3b80d8
This is actually just a module debug info stream, so it should
technically be covered by a discussion of the module list.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@357819 91177308-0d34-0410-b5e6-96231b3b80d8
This necessitates adding a document describing the serialized
hash table format. This document is currently empty, although
it will be filled out in followup patches.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@357784 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Add new ``isa_and_nonnull<>`` operator that works just like
the ``isa<>`` operator, except that it allows for a null pointer as an
argument (which it then returns false).
Reviewers: lattner, aaron.ballman, greened
Reviewed By: lattner
Subscribers: hubert.reinterpretcast, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60291
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@357761 91177308-0d34-0410-b5e6-96231b3b80d8
Since this can be set with s_setreg*, it should not be a subtarget
property. Set a default based on the calling convention, and Introduce
a new amdgpu-dx10-clamp attribute to override this if desired.
Also introduce a new amdgpu-ieee attribute to match.
The values need to match to allow inlining. I think it is OK for the
caller's dx10-clamp attribute to override the callee, but there
doesn't appear to be the infrastructure to do this currently without
definining the attribute in the generic Attributes.td.
Eventually the calling convention lowering will need to insert a mode
switch somewhere for these.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@357302 91177308-0d34-0410-b5e6-96231b3b80d8
Ensure Code Object V2 documentation is complete, but always contains a
warning and a link to the equivalent Code Object V3 documentation.
Explicitly indicate that any note records present in a code object that
are not documented must be considered deprecated and ignored.
Differential Revision: https://reviews.llvm.org/D59782
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@357176 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is an alternative to D59539.
Let's suppose we have measured 4 different opcodes, and got: `0.5`, `1.0`, `1.5`, `2.0`.
Let's suppose we are using `-analysis-clustering-epsilon=0.5`.
By default now we will start processing the `0.5` point, find that `1.0` is it's neighbor, add them to a new cluster.
Then we will notice that `1.5` is a neighbor of `1.0` and add it to that same cluster.
Then we will notice that `2.0` is a neighbor of `1.5` and add it to that same cluster.
So all these points ended up in the same cluster.
This may or may not be a correct implementation of dbscan clustering algorithm.
But this is rather horribly broken for the reasons of comparing the clusters with the LLVM sched data.
Let's suppose all those opcodes are currently in the same sched cluster.
If i specify `-analysis-inconsistency-epsilon=0.5`, then no matter
the LLVM values this cluster will **never** match the LLVM values,
and thus this cluster will **always** be displayed as inconsistent.
The solution is obviously to split off some of these opcodes into different sched cluster.
But how do i do that? Out of 4 opcodes displayed in the inconsistency report,
which ones are the "bad ones"? Which ones are the most different from the checked-in data?
I'd need to go in to the `.yaml` and look it up manually.
The trivial solution is to, when creating clusters, don't use the full dbscan algorithm,
but instead "pick some unclustered point, pick all unclustered points that are it's neighbor,
put them all into a new cluster, repeat". And just so as it happens, we can arrive
at that algorithm by not performing the "add neighbors of a neighbor to the cluster" step.
But that won't work well once we teach analyze mode to operate in on-1D mode
(i.e. on more than a single measurement type at a time), because the clustering would
depend on the order of the measurements.
Instead, let's just create a single cluster per opcode, and put all the points of that opcode into said cluster.
And simultaneously check that every point in that cluster is a neighbor of every other point in the cluster,
and if they are not, the cluster (==opcode) is unstable.
This is //yet another// step to bring me closer to being able to continue cleanup of bdver2 sched model..
Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=40880 | PR40880 ]].
Reviewers: courbet, gchatelet
Reviewed By: courbet
Subscribers: tschuett, jdoerfert, RKSimon, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59820
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@357152 91177308-0d34-0410-b5e6-96231b3b80d8
A section containing metadata on remark diagnostics will be emitted if
the flag (-mllvm) -remarks-section is present.
For now, the metadata is:
* a magic number for remarks: "REMARKS\0"
* the version number: a little-endian uint64_t
* the absolute file path to the serialized remark diagnostics: a
null-terminated string.
Differential Revision: https://reviews.llvm.org/D59571
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@357043 91177308-0d34-0410-b5e6-96231b3b80d8
Just as as llvm IR supports explicitly specifying numeric value ids
for instructions, and emits them by default in textual output, now do
the same for blocks.
This is a slightly incompatible change in the textual IR format.
Previously, llvm would parse numeric labels as string names. E.g.
define void @f() {
br label %"55"
55:
ret void
}
defined a label *named* "55", even without needing to be quoted, while
the reference required quoting. Now, if you intend a block label which
looks like a value number to be a name, you must quote it in the
definition too (e.g. `"55":`).
Previously, llvm would print nameless blocks only as a comment, and
would omit it if there was no predecessor. This could cause confusion
for readers of the IR, just as unnamed instructions did prior to the
addition of "%5 = " syntax, back in 2008 (PR2480).
Now, it will always print a label for an unnamed block, with the
exception of the entry block. (IMO it may be better to print it for
the entry-block as well. However, that requires updating many more
tests.)
Thus, the following is supported, and is the canonical printing:
define i32 @f(i32, i32) {
%3 = add i32 %0, %1
br label %4
4:
ret i32 %3
}
New test cases covering this behavior are added, and other tests
updated as required.
Differential Revision: https://reviews.llvm.org/D58548
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356789 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce a DW_OP_LLVM_convert Dwarf expression pseudo op that allows
for a convenient way to perform type conversions on the Dwarf expression
stack. As an additional bonus it paves the way for using other Dwarf
v5 ops that need to reference a base_type.
The new DW_OP_LLVM_convert is used from lib/Transforms/Utils/Local.cpp
to perform sext/zext on debug values but mainly the patch is about
preparing terrain for adding other Dwarf v5 ops that need to reference a
base_type.
For Dwarf v5 the op maps to DW_OP_convert and for earlier versions a
complex shift & mask pattern is generated to emulate sext/zext.
This is a recommit of r356442 with trivial fixes for the failing tests.
Differential Revision: https://reviews.llvm.org/D56587
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356451 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce a DW_OP_LLVM_convert Dwarf expression pseudo op that allows
for a convenient way to perform type conversions on the Dwarf expression
stack. As an additional bonus it paves the way for using other Dwarf
v5 ops that need to reference a base_type.
The new DW_OP_LLVM_convert is used from lib/Transforms/Utils/Local.cpp
to perform sext/zext on debug values but mainly the patch is about
preparing terrain for adding other Dwarf v5 ops that need to reference a
base_type.
For Dwarf v5 the op maps to DW_OP_convert and for earlier versions a
complex shift & mask pattern is generated to emulate sext/zext.
Differential Revision: https://reviews.llvm.org/D56587
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356442 91177308-0d34-0410-b5e6-96231b3b80d8
Add an experimental buffer fat pointer address space that is currently
unhandled in the backend. This commit reserves address space 7 as a
non-integral pointer repsenting the 160-bit fat pointer (128-bit buffer
descriptor + 32-bit offset) that is heavily used in graphics workloads
using the AMDGPU backend.
Differential Revision: https://reviews.llvm.org/D58957
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356373 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
CoverageExporterJson::renderFiles accounts for most of the execution time given a large profdata file with multiple binaries.
Proposed solution is to generate JSON for each file in parallel and sort at the end to preserve deterministic output. Also added flags to skip generating parts of the output to trim the output size.
Patch by Sajjad Mirza (@sajjadm).
Reviewers: Dor1s, vsk
Reviewed By: Dor1s, vsk
Subscribers: liaoyuke, mgrang, jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59277
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356178 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds a section, ``Object lifetime in optimized code'', that
documents how such intrinsics are supposed to be handled. It sets out some of
the principles of how they specify variable locations, and how long those
locations are valid for.
This patch also documents one of the objectives behind the variable-location
design, that we should never allow the debugger to observe a state of the
program that would not have appeared without optimization.
Differential Revision: https://reviews.llvm.org/D58726
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356041 91177308-0d34-0410-b5e6-96231b3b80d8
This indicates an intrinsic parameter is required to be a constant,
and should not be replaced with a non-constant value.
Add the attribute to all AMDGPU and generic intrinsics that comments
indicate it should apply to. I scanned other target intrinsics, but I
don't see any obvious comments indicating which arguments are intended
to be only immediates.
This breaks one questionable testcase for the autoupgrade. I'm unclear
on whether the autoupgrade is supposed to really handle declarations
which were never valid. The verifier fails because the attributes now
refer to a parameter past the end of the argument list.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@355981 91177308-0d34-0410-b5e6-96231b3b80d8
Add a note about legacy FunctionPassManager to the LLVM tutorial.
It seems to confuse some people, worth adding a warning to the tutorial
to elaborate and suggest using `llvm::legacy::FunctionPassManager` for
now. Not a perfect solution but hopefully will avoid confusion
in the meantime.
Differential Revision: https://reviews.llvm.org/D59258
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@355930 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Right now, when we encounter a string equality check,
e.g. `if (memcmp(a, b, s) == 0)`, we try to expand to a comparison if `s` is a
small compile-time constant, and fall back on calling `memcmp()` else.
This is sub-optimal because memcmp has to compute much more than
equality.
This patch replaces `memcmp(a, b, s) == 0` by `bcmp(a, b, s) == 0` on platforms
that support `bcmp`.
`bcmp` can be made much more efficient than `memcmp` because equality
compare is trivially parallel while lexicographic ordering has a chain
dependency.
Subscribers: fedor.sergeev, jyknight, ckennelly, gchatelet, llvm-commits
Differential Revision: https://reviews.llvm.org/D56593
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@355672 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The current install-clang-headers target installs clang's resource
directory headers. This is different from the install-llvm-headers
target, which installs LLVM's API headers. We want to introduce the
corresponding target to clang, and the natural name for that new target
would be install-clang-headers. Rename the existing target to
install-clang-resource-headers to free up the install-clang-headers name
for the new target, following the discussion on cfe-dev [1].
I didn't find any bots on zorg referencing install-clang-headers. I'll
send out another PSA to cfe-dev to accompany this rename.
[1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html
Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille
Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits
Tags: #clang, #sanitizers, #lldb, #openmp, #llvm
Differential Revision: https://reviews.llvm.org/D58791
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@355340 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds a new flag named -bottleneck-analysis to print out information
about throughput bottlenecks.
MCA knows how to identify and classify dynamic dispatch stalls. However, it
doesn't know how to analyze and highlight kernel bottlenecks. The goal of this
patch is to teach MCA how to correlate increases in backend pressure to backend
stalls (and therefore, the loss of throughput).
From a Scheduler point of view, backend pressure is a function of the scheduler
buffer usage (i.e. how the number of uOps in the scheduler buffers changes over
time). Backend pressure increases (or decreases) when there is a mismatch
between the number of opcodes dispatched, and the number of opcodes issued in
the same cycle. Since buffer resources are limited, continuous increases in
backend pressure would eventually leads to dispatch stalls. So, there is a
strong correlation between dispatch stalls, and how backpressure changed over
time.
This patch teaches how to identify situations where backend pressure increases
due to:
- unavailable pipeline resources.
- data dependencies.
Data dependencies may delay execution of instructions and therefore increase the
time that uOps have to spend in the scheduler buffers. That often translates to
an increase in backend pressure which may eventually lead to a bottleneck.
Contention on pipeline resources may also delay execution of instructions, and
lead to a temporary increase in backend pressure.
Internally, the Scheduler classifies instructions based on whether register /
memory operands are available or not.
An instruction is marked as "ready to execute" only if data dependencies are
fully resolved.
Every cycle, the Scheduler attempts to execute all instructions that are ready
to execute. If an instruction cannot execute because of unavailable pipeline
resources, then the Scheduler internally updates a BusyResourceUnits mask with
the ID of each unavailable resource.
ExecuteStage is responsible for tracking changes in backend pressure. If backend
pressure increases during a cycle because of contention on pipeline resources,
then ExecuteStage sends a "backend pressure" event to the listeners.
That event would contain information about instructions delayed by resource
pressure, as well as the BusyResourceUnits mask.
Note that ExecuteStage also knows how to identify situations where backpressure
increased because of delays introduced by data dependencies.
The SummaryView observes "backend pressure" events and prints out a "bottleneck
report".
Example of bottleneck report:
```
Cycles with backend pressure increase [ 99.89% ]
Throughput Bottlenecks:
Resource Pressure [ 0.00% ]
Data Dependencies: [ 99.89% ]
- Register Dependencies [ 0.00% ]
- Memory Dependencies [ 99.89% ]
```
A bottleneck report is printed out only if increases in backend pressure
eventually caused backend stalls.
About the time complexity:
Time complexity is linear in the number of instructions in the
Scheduler::PendingSet.
The average slowdown tends to be in the range of ~5-6%.
For memory intensive kernels, the slowdown can be significant if flag
-noalias=false is specified. In the worst case scenario I have observed a
slowdown of ~30% when flag -noalias=false was specified.
We can definitely recover part of that slowdown if we optimize class LSUnit (by
doing extra bookkeeping to speedup queries). For now, this new analysis is
disabled by default, and it can be enabled via flag -bottleneck-analysis. Users
of MCA as a library can enable the generation of pressure events through the
constructor of ExecuteStage.
This patch partially addresses https://bugs.llvm.org/show_bug.cgi?id=37494
Differential Revision: https://reviews.llvm.org/D58728
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@355308 91177308-0d34-0410-b5e6-96231b3b80d8
This patch allows all forms of values for options to be used at the end
of a group. With the fix, it is possible to follow the way GNU binutils
tools handle grouping options better. For example, the -j option can be
used with objdump in any of the following ways:
$ objdump -d -j .text a.o
$ objdump -d -j.text a.o
$ objdump -dj .text a.o
$ objdump -dj.text a.o
Differential Revision: https://reviews.llvm.org/D58711
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@355185 91177308-0d34-0410-b5e6-96231b3b80d8
If an option, which requires a value, has a `cl::Grouping` formatting
modifier, it works well as far as it is used at the end of a group,
or as a separate argument. However, if the option appears accidentally
in the middle of a group, the program just crashes. This patch prints
an error message instead.
Differential Revision: https://reviews.llvm.org/D58499
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@355184 91177308-0d34-0410-b5e6-96231b3b80d8
Part 2 of CSPGO changes (mostly related to ProfileSummary).
Note that I use a default parameter in setProfileSummary() and getSummary().
This is to break the dependency in clang. I will make the parameter explicit
after changing clang in a separated patch.
Differential Revision: https://reviews.llvm.org/D54175
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@355131 91177308-0d34-0410-b5e6-96231b3b80d8
We have all the necessary legalization, expansion and unrolling support required for the *.overflow intrinsics with vector types, so update the docs to make that clear.
Note: vectorization is not in place yet (the non-homogenous return types aren't well supported) so we still must explicitly use the vectors intrinsics and not reply on slp/loop.
Differential Revision: https://reviews.llvm.org/D58618
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354821 91177308-0d34-0410-b5e6-96231b3b80d8
As mentioned in D58359, we can explicitly state that the
memory allocated is uninitialized and reading that memory
produces undef.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354394 91177308-0d34-0410-b5e6-96231b3b80d8
The patch adds support for --hash-filenames to llvm-cov. This option adds md5
hash of the source path to the name of the generated .gcov file. The option is
crucial for cases where you have multiple files with the same name but can't
use --preserve-paths as resulting filenames exceed the limit.
from gcov(1):
```
-x
--hash-filenames
By default, gcov uses the full pathname of the source files to to
create an output filename. This can lead to long filenames that
can overflow filesystem limits. This option creates names of the
form source-file##md5.gcov, where the source-file component is
the final filename part and the md5 component is calculated from
the full mangled name that would have been used otherwise.
```
Patch by Igor Ignatev!
Differential Revision: https://reviews.llvm.org/D58370
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354379 91177308-0d34-0410-b5e6-96231b3b80d8
