Avoid unnecessary spills of byval arguments of device functions to
local space on SASS level and subsequent pointer conversion to generic
address space that follows. Instead, make a local copy in IR, provide
a way to access arguments directly, and let LLVM optimize the copy away
when possible.
Differential Review: https://reviews.llvm.org/D21421
llvm-svn: 276153
Summary:
A sysroot without c++ headers is able to build compiler-rt, don't
require them when configuring available architectures from cmake.
Reviewers: samsonov, beanz, compnerd
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D22469
llvm-svn: 276151
Summary:
Mirroring most cleanup changed from compiler-rt/lib/builtins/cpu_model.
x86 methods are still returning a bool.
Reviewers: llvm-commits, echristo, craig.topper, sanjoy
Subscribers: mehdi_amini
Differential Revision: https://reviews.llvm.org/D22480
llvm-svn: 276149
Summary:
Use stricter comparisons for architecture. This prevents cmake from failing
for sysroots which can only compile armhf and not arm, since
arm MATCHES armhf is true, while arm STREQUAL armhf is false.
Reviewers: beanz, compnerd
Subscribers: aemerson, llvm-commits
Differential Revision: https://reviews.llvm.org/D22473
llvm-svn: 276148
We will need to do something like this to support range extension
thunks since that process is iterative.
Doing this also has the advantage that when doing the regular
relocation scan the offset in the output section is known and we can
just store that. This reduces the number of times we have to run
getOffset and I think will allow a more specialized .eh_frame
representation.
By itself this is already a performance win.
firefox
master 7.295045737
patch 7.209466989 0.98826892235
chromium
master 4.531254468
patch 4.509221804 0.995137623774
chromium fast
master 1.836928973
patch 1.823805241 0.992855612714
the gold plugin
master 0.379768791
patch 0.380043405 1.00072310839
clang
master 0.642698284
patch 0.642215663 0.999249070657
llvm-as
master 0.036665467
patch 0.036456225 0.994293213284
the gold plugin fsds
master 0.40395817
patch 0.404384555 1.0010555177
clang fsds
master 0.722045545
patch 0.720946135 0.998477367518
llvm-as fsds
master 0.03292646
patch 0.032759965 0.994943428477
scylla
master 3.427376378
patch 3.368316181 0.98276810292
llvm-svn: 276146
Summary:
The format style is set to LLVM. This is consistent with the
parallel-libs project charter which specifies that its libraries will
conform to LLVM coding style.
Reviewers: jlebar
Subscribers: parallel_libs-commits
Differential Revision: https://reviews.llvm.org/D22576
llvm-svn: 276145
This patch simplifies output section management by making
Factory class have ownership of sections that creates.
Differential Revision: https://reviews.llvm.org/D22575
llvm-svn: 276141
As noted in https://reviews.llvm.org/D22537 , we can use this functionality in
visitSelectInstWithICmp() and InstSimplify, but currently we have duplicated
code.
llvm-svn: 276140
Previously it was harder to read and also has a error:
command kind was not checked.
Differential revision: https://reviews.llvm.org/D22574
llvm-svn: 276137
In D12090, the ExprValueMap was added to reuse existing value during SCEV expansion.
However, const folding and sext/zext distribution can make the reuse still difficult.
A simplified case is: suppose we know S1 expands to V1 in ExprValueMap, and
S1 = S2 + C_a
S3 = S2 + C_b
where C_a and C_b are different SCEVConstants. Then we'd like to expand S3 as
V1 - C_a + C_b instead of expanding S2 literally. It is helpful when S2 is a
complex SCEV expr and S2 has no entry in ExprValueMap, which is usually caused
by the fact that S3 is generated from S1 after const folding.
In order to do that, we represent ExprValueMap as a mapping from SCEV to
ValueOffsetPair. We will save both S1->{V1, 0} and S2->{V1, C_a} into the
ExprValueMap when we create SCEV for V1. When S3 is expanded, it will first
expand S2 to V1 - C_a because of S2->{V1, C_a} in the map, then expand S3 to
V1 - C_a + C_b.
Differential Revision: https://reviews.llvm.org/D21313
llvm-svn: 276136
Should fix the Windows buildbots, and maybe some other non-Linux Unix
bots too.
XRay currently depends on sanitizer_common, so associate it with the
"build sanitizers" option and remove the option for separately
controlling the XRay build.
llvm-svn: 276124
- R_ARM_TLS_LDM32
- R_ARM_TLS_LDO32
The local dynamic implementation and tests follows the same model as
the other ARM TLS models. The R_ARM_TLS_LDO32 is implemented as R_ABS
expr type as the getVA() for a TLS symbol will return the offset from the
start of the TLS block.
Differential Revision https://reviews.llvm.org/D22563
llvm-svn: 276123
Summary:
This test is allocating a 1gig chunk to make shadow allocation failed,
but on 64-bits architecture the test is working.
Reviewers: rnk
Subscribers: kubabrecka, llvm-commits, wang0109, chrisha
Differential Revision: https://reviews.llvm.org/D22553
llvm-svn: 276122
'ReusingBase' was a terrible name. It might actually refer to the most
derived class, which is not a base. 'BaseWithVPtr' was also bad, since
again, it could refer to the most derived class. It was actually the
first base to introduce the vptr, so now it is 'IntroducingObject'.
llvm-svn: 276120
Under MSVS 2015 I observed integral constant overflow warning when aggregate initialization was used
to init the bit field. Patch fixes that.
llvm-svn: 276118
Summary:
This patch implements the initialisation and patching routines for the XRay runtime, along with the necessary trampolines for function entry/exit handling. For now we only define the basic hooks for allowing an implementation to define a handler that gets run on function entry/exit. We expose a minimal API for controlling the behaviour of the runtime (patching, cleanup, and setting the handler to invoke when instrumenting).
Depends on D19904
Reviewers: echristo, kcc, rnk
Subscribers: rnk, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D21612
llvm-svn: 276117
Summary:
Previoly, the added test failed with the fillowing fixit:
char v[5];
- for(size_t i = 0; i < 5; ++i)
+ for(char value : v)
{
- unsigned char value = v[i];
if (value > 127)
i.e. the variable 'value' changes from unsigned char to signed char. And
thus the following 'if' does not work anymore.
With this commit, the fixit is changed to:
char v[5];
- for(size_t i = 0; i < 5; ++i)
+ for(unsigned char value : v)
{
- unsigned char value = v[i];
if (value > 127)
Reviewers: alexfh, klimek
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D22069
llvm-svn: 276111
Lots of blocks had "llvm" or "nasm" syntax types but either weren't following
the syntax, or the syntax has changed (and sphinx hasn't keep up) or the type
doesn't even exist (nasm?).
Other documents had :options: what were invalid. I only removed those that had
warnings, and left the ones that didn't, in order to follow the principle of
least surprise.
This is like this for ages, but the buildbot is now failing on errors. It may
take a while to upgrade the buildbot's sphinx, if that's even possible, but
that shouldn't stop us from getting docs updates (which seem down for quite
a while).
Also, we're not losing any syntax highlight, since when it doesn't parse, it
doesn't colour. Ie. those blocks are not being highlighted anyway.
I'm trying to get all docs in one go, so that it's easy to revert later if we
do fix, or at least easy to know what's to fix.
llvm-svn: 276109
In here we are iterating relocations in order, so we can do the same
with the pieces of .eh_frame and avoid a binary search.
The link times I got with this patch were:
firefox
master 7.22977811
patch 7.141041442 0.987726225252
chromium
master 4.478966851
patch 4.506602207 1.00617002914
chromium fast
master 1.894713371
patch 1.866446889 0.98508139414
the gold plugin
master 0.386193907
patch 0.382374918 0.990111213743
clang
master 0.654849589
patch 0.647899815 0.989387220949
llvm-as
master 0.037212718
patch 0.036858172 0.990472450843
the gold plugin fsds
master 0.410876711
patch 0.407418613 0.991583611562
clang fsds
master 0.734623069
patch 0.728237526 0.991307728726
llvm-as fsds
master 0.033446197
patch 0.03302833 0.987506292569
scylla
master 3.38134402
patch 3.414188846 1.00971354166
llvm-svn: 276108
Currently fails as:
gotsan.cc: In function 'void* __sanitizer::__libc_memalign(__sanitizer::uptr, __sanitizer::uptr)':
gotsan.cc:6194:50: error: 'posix_memalign' was not declared in this scope
uptr error = posix_memalign(&p, alignment, size);
Windows does not provide posix_memalign.
llvm-svn: 276107
Summary: In r275989 we enabled the folding of `logic(cast(icmp), cast(icmp))` to `cast(logic(icmp, icmp))`. Here we add more test cases to assure this folding works for all logical operations `and`/`or`/`xor`.
Reviewers: grosser
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D22561
Contributed-by: Matthias Reisinger
llvm-svn: 276105
This patch adds costs for the vectorized implementations of CTPOP, the default values were seriously underestimating the cost of these and was encouraging vectorization on targets where serialized use of POPCNT would be much better.
Differential Revision: https://reviews.llvm.org/D22456
llvm-svn: 276104
D20859 and D20860 attempted to replace the SSE (V)CVTTPS2DQ and VCVTTPD2DQ truncating conversions with generic IR instead.
It turns out that the behaviour of these intrinsics is different enough from generic IR that this will cause problems, INF/NAN/out of range values are guaranteed to result in a 0x80000000 value - which plays havoc with constant folding which converts them to either zero or UNDEF. This is also an issue with the scalar implementations (which were already generic IR and what I was trying to match).
This patch changes both scalar and packed versions back to using x86-specific builtins.
It also deals with the other scalar conversion cases that are runtime rounding mode dependent and can have similar issues with constant folding.
Differential Revision: https://reviews.llvm.org/D22105
llvm-svn: 276102
Retry r275776 (no changes, we suspect the issue was with another commit).
The current logic for handling inline asm operands in DAGToDAGISel interprets
the operands by looking for constants, which should represent the flags
describing the kind of operand we're dealing with (immediate, memory, register
def etc). The operands representing actual data are skipped only if they are
non-const, with the exception of immediate operands which are skipped explicitly
when a flag describing an immediate is found.
The oversight is that memory operands may be const too (e.g. for device drivers
reading a fixed address), so we should explicitly skip the operand following a
flag describing a memory operand. If we don't, we risk interpreting that
constant as a flag, which is definitely not intended.
Fixes PR26038
Differential Revision: https://reviews.llvm.org/D22103
llvm-svn: 276101
Alina Sbirlea