| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
See http://reviews.llvm.org/D22613, http://reviews.llvm.org/D22614
llvm-svn: 276356
|
| |
|
|
|
|
|
|
| |
This eliminates unncessary calls and init functions.
Differential Revision: http://reviews.llvm.org/D22614
llvm-svn: 276355
|
| |
|
|
|
|
|
|
| |
This eliminates unncessary calls and init functions.
Differential Revision: http://reviews.llvm.org/D22613
llvm-svn: 276354
|
| |
|
|
| |
llvm-svn: 276353
|
| |
|
|
|
|
|
|
|
|
| |
rewriteBuiltinFunctionDecl can encounter errors when performing
DefaultFunctionArrayLvalueConversion. These errors were not handled
which led to a null pointer dereference.
This fixes PR28651.
llvm-svn: 276352
|
| |
|
|
|
|
|
| |
when Dumping, thanks to Devin to catching the edit mistake I made in
r276079.
llvm-svn: 276351
|
| |
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D22542
llvm-svn: 276350
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D22648
llvm-svn: 276349
|
| |
|
|
|
|
|
|
|
|
| |
When we failed to parse a function in the mir parser, we should abort
the whole compilation instead of continuing in a weird state. Indeed,
this was creating strange machine function passes failures that were
hard to understand, until we notice that the function actually did not
get parsed correctly!
llvm-svn: 276348
|
| |
|
|
|
|
|
| |
This variant is (as documented in the TD) for disassembler use only, and should
not be used in patterns - it is longer, and is broken on 64-bit.
llvm-svn: 276347
|
| |
|
|
| |
llvm-svn: 276346
|
| |
|
|
| |
llvm-svn: 276345
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when constraint "w" is used on a 32-bit operand.
This enables compiling the following code, which used to error out in
the backend:
void foo1(int a) {
asm volatile ("sqxtn h0, %s0\n" : : "w"(a):);
}
Fixes PR28633.
llvm-svn: 276344
|
| |
|
|
| |
llvm-svn: 276343
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instead of LLVM_INCLUDE_TESTS.
This does not change anything by default since LLVM_INCLUDE_UTILS is already set
to TRUE by default. In addition, since LLVM_INCLUDE_TESTS => LLVM_INCLUDE_UTILS,
the only way that this can cause changes is in the case where LLVM_INCLUDE_UTILS
is set to TRUE, but LLVM_INCLUDE_TESTS is FALSE. In that case, building gtest is
not a huge cost.
The reason to do this is that without this change, one can not turn off
LLVM_INCLUDE_TESTS in downstream projects that also use gtest for unittests. It
also just in general makes more sense since LLVM_INCLUDE_UTILS gates FileCheck
and other utilities that are along the lines of gtest.
Additionally from talking with chandlerc, this was not done for any specific
reason, so there is no reason not to do it and lots of benefit to doing it.
llvm-svn: 276342
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
simplifications (PR28466)
rL245171 exposed a hole in InstSimplify that manifested in a strange way in PR28466:
https://llvm.org/bugs/show_bug.cgi?id=28466
It's possible to use trunc + icmp sgt/slt in place of an and + icmp eq/ne, so we need to
recognize that pattern to eliminate selects that are choosing between some value and some
bitmasked version of that value.
Note that there is significant room for improvement (refactoring) and enhancement (more
patterns, possibly in InstCombine rather than here).
Differential Revision: https://reviews.llvm.org/D22537
llvm-svn: 276341
|
| |
|
|
| |
llvm-svn: 276340
|
| |
|
|
|
|
|
|
|
|
|
| |
This patch moves the update instruction for vectorized integer induction phi
nodes to the end of the latch block. This ensures consistent placement of all
induction updates across all the kinds of int inductions we create (scalar,
splat vector, or vector phi).
Differential Revision: https://reviews.llvm.org/D22416
llvm-svn: 276339
|
| |
|
|
|
|
| |
I wonder what is the most idiomatic way to write this.
llvm-svn: 276338
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Some instructions can only be copied if the relative offset is adjusted.
This patch adds support for two common instruction.
It's quite common to have a indirect load in the prologue
(loading the security cookie).
Reviewers: rnk
Subscribers: llvm-commits, wang0109, chrisha
Differential Revision: https://reviews.llvm.org/D22647
llvm-svn: 276336
|
| |
|
|
| |
llvm-svn: 276335
|
| |
|
|
|
|
|
|
| |
std::numeric_limits<int64_t>::max() is not constexpr in VC 2013 headers,
and Clang complains that it isn't. MSVC 2013 itself is emitting a
dynamic initializer for this thing. Instead, use an enum.
llvm-svn: 276334
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch fixes cross-architecture compilation,
by allowing flags like -target and --sysroot to be set for
architecture testing and compilation.
Reviewers: tberghammer, srhines, danalbert, beanz, compnerd
Subscribers: tberghammer, llvm-commits, danalbert
Differential Revision: https://reviews.llvm.org/D22415
llvm-svn: 276333
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The OOM test should really only run on 32-bits, since it's hard to OOM
on x64.
The operator_array_new_with_dtor_left_oob tests need to account for the
larger array cookie on x64 (8 bytes instead of 4).
Use -std=c++14 in use-after-scope-capture.cc to avoid errors in the MSVC
2015 STL on Windows. The default there is C++14 anyway.
llvm-svn: 276332
|
| |
|
|
|
|
|
|
| |
Having the added `\brief` made doxygen interpret it as the summary for
the `llvm` namespace (visible at:
http://llvm.org/doxygen/namespaces.html).
llvm-svn: 276331
|
| |
|
|
|
|
|
|
|
|
| |
Move needsComdatForCounter() to lib/ProfileData/InstrProf.cpp from
lib/Transforms/Instrumentation/InstrProfiling.cpp to make is available for
other files.
Differential Revision: https://reviews.llvm.org/D22643
llvm-svn: 276330
|
| |
|
|
|
|
|
|
|
|
| |
Not all relocations from a .eh_frame that point to an executable
section should be ignored. In particular, the relocation finding the
personality function should not.
This is a reduction from trying to bootstrap a static lld on linux.
llvm-svn: 276329
|
| |
|
|
| |
llvm-svn: 276328
|
| |
|
|
|
|
| |
Also remove the needless static that was using them.
llvm-svn: 276327
|
| |
|
|
| |
llvm-svn: 276326
|
| |
|
|
|
|
|
|
| |
Given that other proposals are making their way through, it's better if we
specify what GitHub proposal this is, in case there are others that also
involve GitHub, but not sub-modules.
llvm-svn: 276325
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch is fixing running interception unittests for memcpy/memmove on
windows 64.
Reviewers: rnk
Subscribers: llvm-commits, wang0109, kubabrecka, chrisha
Differential Revision: https://reviews.llvm.org/D22641
llvm-svn: 276324
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DATA_SEGMENT_END, CONSTANT
It is called basic because:
CONSTANT expression can refer to COMMONPAGESIZE and MAXPAGESIZE.
This sizes are usually different and used for possible optimization of
memory consumption.
More details are here: https://sourceware.org/ml/binutils/2002-02/msg00265.html
We currently do not support this optimization, so both CONSTANT(MAXPAGESIZE)
and CONSTANT(COMMONPAGESIZE) just return Target->PageSize value.
DATA_SEGMENT_ALIGN and DATA_SEGMENT_END are used as a part of opt.
The latter one is just ignored now.
According to documentation DATA_SEGMENT_ALIGN has 2 possible
calculation, but since we do not support mentioned opt - it
is always calculated now as (ALIGN(MAXPAGESIZE) + (. & (MAXPAGESIZE - 1))).
In general this should work for now until we deside to support this opt.
Differential revision: https://reviews.llvm.org/D19663
llvm-svn: 276323
|
| |
|
|
| |
llvm-svn: 276322
|
| |
|
|
| |
llvm-svn: 276321
|
| |
|
|
|
|
| |
This reverts commit r276316.
llvm-svn: 276320
|
| |
|
|
| |
llvm-svn: 276319
|
| |
|
|
|
|
| |
SizeClassMap::MaxCached; ensure that TransferBatch size is a power of two, refactor TransferBatch creation/destruction into separate functions.
llvm-svn: 276318
|
| |
|
|
|
|
| |
Another attempt at r276271, hopefully without breaking ModuleDebugInfo test.
llvm-svn: 276317
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The llvm.invariant.start and llvm.invariant.end intrinsics currently
support specifying invariant memory objects only in the default address space.
With this change, these intrinsics are overloaded for any adddress space for memory objects
and we can use these llvm invariant intrinsics in non-default address spaces.
Example: llvm.invariant.start.p1i8(i64 4, i8 addrspace(1)* %ptr)
This overloaded intrinsic is needed for representing final or invariant memory in managed languages.
Reviewers: tstellarAMD, reames, apilipenko
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D22519
llvm-svn: 276316
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
It doesn't appear to like this pattern:
for (auto X : Xs)
if (...) { ... }
else ...;
We have heard anecdotes that range based for loops are implemented as a
token rewrite in MSVC's lexer, and that the most challenging part of the
rewrite is finding the end of the for loop. That makes sense, given that
it's a lexer.
llvm-svn: 276315
|
| |
|
|
|
|
|
|
|
|
| |
Make kStderrFd a macro to avoid dynamic initialization of the
report_file global. This actually causes a crash at runtime, because
ASan initializes before static initializers run.
Remove an unused variable in asan_win.cc.
llvm-svn: 276314
|
| |
|
|
| |
llvm-svn: 276313
|
| |
|
|
|
|
| |
Also, rename some of them for consistency and to follow current conventions.
llvm-svn: 276312
|
| |
|
|
|
|
| |
AppleClang can't compile the assignment expression.
llvm-svn: 276311
|
| |
|
|
| |
llvm-svn: 276310
|
| |
|
|
|
|
| |
The value I'd picked was correct, as per the recently published SG10 paper http://wg21.link/p0096r3
llvm-svn: 276309
|
| |
|
|
|
|
| |
This commit adds a generic SUB opcode to global-isel.
llvm-svn: 276308
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously LLVM_HAS_GLOBAL_ISEL would directly get the value of
LLVM_BUILD_GLOBAL_ISEL. This could be any integer value and not just ON
and OFF. The problem is that lit.cfg was checking for ON to define that
global-isel was supported, thus if we were setting
LLVM_BUILD_GLOBAL_ISEL with an integer value, say 1, this test would
fail whereas we do build global-isel and want to test it.
llvm-svn: 276307
|
| |
|
|
|
|
|
|
| |
Previously LLVM_BUILD_GLOBAL_ISEL was a boolean variable and although,
this is strictly identical to an option, it did not convey the
information that the user may set it. Options are here for that.
llvm-svn: 276306
|