Add a "-j" option to llvm-profdata to control the number of threads used.
Auto-detect NumThreads when it isn't specified, and avoid spawning threads when
they wouldn't be beneficial.
I tested this patch using a raw profile produced by clang (147MB). Here is the
time taken to merge 4 copies together on my laptop:
No thread pool: 112.87s user 5.92s system 97% cpu 2:01.08 total
With 2 threads: 134.99s user 26.54s system 164% cpu 1:33.31 total
Changes since the initial commit:
- When handling odd-length inputs, call ThreadPool::wait() before merging the
last profile. Should fix a race/off-by-one (see r275937).
Differential Revision: https://reviews.llvm.org/D22438
llvm-svn: 275938
For instructions in uniform set, they will not have vector versions so
add them to VecValuesToIgnore.
For induction vars, those only used in uniform instructions or consecutive
ptrs instructions have already been added to VecValuesToIgnore above. For
those induction vars which are only used in uniform instructions or
non-consecutive/non-gather scatter ptr instructions, the related phi and
update will also be added into VecValuesToIgnore set.
The change will make the vector RegUsages estimation less conservative.
Differential Revision: https://reviews.llvm.org/D20474
The recommit fixed the testcase global_alias.ll.
llvm-svn: 275936
This is to help moveSILowerControlFlow to before regalloc.
There are a couple of tradeoffs with this. The complete CFG
is visible to more passes, the loop body avoids an extra copy of m0,
vcc isn't required, and immediate offsets can be shrunk into s_movk_i32.
The disadvantage is the register allocator doesn't understand that
the single lane's vector is dead within the loop body, so an extra
register is used to outlive the loop block when expanding the
VGPR -> m0 loop. This also now results in worse waitcnt insertion
before the loop instead of after for pending operations at the point
of the indexing, but that should be fixed by future improvements to
cross block waitcnt insertion.
v_movreld_b32's operands are now modeled more correctly since vdst
is not a true output. This is kind of a hack to treat vdst as a
use operand. Extra checking is required in the verifier since
I can't seem to get tablegen to emit an implicit operand for a
virtual register.
llvm-svn: 275934
Add an overview of stubs and compile callbacks before the discussion of the
source changes.
-- This line, and those below, will be ignored--
M docs/tutorial/BuildingAJIT3.rst
llvm-svn: 275933
Summary:
This patch adds clang system include path when offloading tool chains, e.g. CUDA, are used in the current compilation.
This fixes an issue detected by @rsmith in response to r275645.
Reviewers: rsmith, tra
Subscribers: rsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D22490
llvm-svn: 275931
This is for a situation where the encoding for a register may be
different depending on the specific operand. For some instructions,
we want to apply additional restrictions beyond the encoding's
constraints.
In AMDGPU some operands are VSrc_32, using the VS_32 pseudo register
class which accept VGPRs, SGPRs, or immediates in the encoding.
Some specific instructions with the same encoding operand do not want
to allow immediates or SGPRs, but the encoding format is different
in this case than a regular VGPR_32 operand.
This allows specifying the encoding should be treated the same
without introducing yet another dummy register class.
llvm-svn: 275929
Instead of extracting raw coverage mappings into an artifact directory,
actually generate useful html reports for a given list of binaries with
symbol demangling turned on.
No tests, but this is actively being used to drive the (still nascent)
coverage bot.
llvm-svn: 275927
Having the following code pattern will result in incorrect diagnostic
int main() {
int arr[10];
#pragma omp target data map(arr[:])
#pragma omp target map(arr)
{}
}
t.cpp:4:24: error: original storage of expression in data environment is shared
but data environment do not fully contain mapped expression storage
#pragma omp target map(arr)
^~~
t.cpp:3:29: note: used here
#pragma omp target data map(arr[:])
^~~~~~
1 error generated.
Patch by David S.
Differential Revision: https://reviews.llvm.org/D22075
llvm-svn: 275926
Add a "-j" option to llvm-profdata to control the number of threads
used. Auto-detect NumThreads when it isn't specified, and avoid spawning
threads when they wouldn't be beneficial.
I tested this patch using a raw profile produced by clang (147MB). Here is the
time taken to merge 4 copies together on my laptop:
No thread pool: 112.87s user 5.92s system 97% cpu 2:01.08 total
With 2 threads: 134.99s user 26.54s system 164% cpu 1:33.31 total
Differential Revision: https://reviews.llvm.org/D22438
llvm-svn: 275921
This fixes the issue of having duplicate entries for the same file in a
coverage report s.t none of the entries actually displayed the correct
coverage information.
llvm-svn: 275913
For instructions in uniform set, they will not have vector versions so
add them to VecValuesToIgnore.
For induction vars, those only used in uniform instructions or consecutive
ptrs instructions have already been added to VecValuesToIgnore above. For
those induction vars which are only used in uniform instructions or
non-consecutive/non-gather scatter ptr instructions, the related phi and
update will also be added into VecValuesToIgnore set.
The change will make the vector RegUsages estimation less conservative.
Differential Revision: https://reviews.llvm.org/D20474
llvm-svn: 275912
Summary:
Per D22441, MSVC warns on our old implementation of isUInt<64>. It sees
uint64_t(1) << 64 and doesn't realize that it's not going to be
executed. Writing as a template specialization is ugly, but prevents
the warning.
Reviewers: RKSimon
Subscribers: majnemer, llvm-commits
Differential Revision: https://reviews.llvm.org/D22472
llvm-svn: 275909
Give incompatible function pointer warning its own diagnostic group
but still leave it as a subgroup of incompatible-pointer-types. This is in
preparation to promote -Wincompatible-function-pointer-types to error on
darwin.
Differential Revision: https://reviews.llvm.org/D22248
rdar://problem/12907612
llvm-svn: 275907
This doesn't seem to work with Bash:
$ /work/llvm/utils/release/merge.sh --proj llvm --rev r275870
/work/llvm/utils/release/merge.sh: line 34: ${$1#r}: bad substitution
I get the same error with and without a leading 'r'.
llvm-svn: 275898
Compute an effective target triple exactly once in ConstructJob(), and
then simply pass around references to it. This eliminates wasteful
re-computation of effective triples (e.g in getARMFloatABI()).
Differential Revision: https://reviews.llvm.org/D22290
llvm-svn: 275895
No in-tree targets access this `DefaultTargetTriple` directly, and usage
of default triples is generally discouraged. Make the field private.
This is part of en effort to make the clang driver use effective triples
more pervasively.
Differential Revision: https://reviews.llvm.org/D22289
llvm-svn: 275894
Taking address of a byval variable in PTX is legal, but currently runs
into miscompilation by ptxas on sm_50+ (NVIDIA issue 1789042).
Work around the issue by enforcing minimum alignment on byval arguments
of device functions.
The change is a no-op on SASS level for sm_3x where ptxas already aligns
local copy by at least 4.
Differential Revision: https://reviews.llvm.org/D22428
llvm-svn: 275893
Summary:
Indirect load are relative offset from RIP.
The current trampoline implementation is incorrectly
copying these instructions which make some unittests
crashing.
This patch is not fixing the unittests but it's fixing
the crashes. The functions are no longer hooked.
Patches will come soon to fix these unittests.
Reviewers: rnk
Subscribers: llvm-commits, wang0109, chrisha
Differential Revision: https://reviews.llvm.org/D22410
llvm-svn: 275892
Summary:
Usually LCSSA survives this transformation, but in some cases (see
attached test) it doesn't: values from the original loop after
separating might be used from the outer loop. Before the transformation
it was the same loop, so LCSSA phis were not required.
This fixes PR28272.
Reviewers: sanjoy, hfinkel, chandlerc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D21665
llvm-svn: 275891
Summary:
The trampoline allocation limits the memory scanning to 1 gig.
There is an unittest that is allocating a large object which make
it impossible to the trampoline allocator to find a free spot.
see shadow_mapping_failures:
```
char bigchunk[1 << 30];
```
This patch is not fixing the unittest but it's fixing it's infinite
loop behavior.
Reviewers: rnk
Subscribers: llvm-commits, wang0109, chrisha
Differential Revision: https://reviews.llvm.org/D22471
llvm-svn: 275887
Vedant Kumar