| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
This is the same change on ARM as r255821 on AArch64.
rdar://9001553
llvm-svn: 257424
|
| |
|
|
|
|
| |
the result of the computations. With that, don't do any mutations if memcmp/etc returned 0
llvm-svn: 257423
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Function::copyAttributesFrom will copy the personality function, prefix
data and prolog data from the source function to the new function, and
is invoked when the IRMover copies the function prototype. This puts a
reference to a constant in the source module on a function in the dest
module, which causes an error when deleting the source module after
importing, since the personality function in the source module still has
uses (this would presumably also be an issue for the prologue and prefix
data). Remove the copies added to the dest copy when creating the new
prototype, as they are mapped properly when/if we link the function body.
llvm-svn: 257420
|
| |
|
|
| |
llvm-svn: 257419
|
| |
|
|
|
|
| |
rdar://9001553
llvm-svn: 257417
|
| |
|
|
|
|
|
|
| |
Currently WebAssembly has two kinds of relocations; data addresses and
function addresses. This adds ELF relocations for them, as well as an
MC symbol kind to indicate which type of relocation is needed.
llvm-svn: 257416
|
| |
|
|
|
|
|
|
|
| |
Apparently the preferred version is the incredibly complicated
VerifyVersionInfoW function.
Rename the function to avoid potential future name clashes.
llvm-svn: 257415
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also, add tests to verify that we're checking 'fast' on both calls of each transform pair,
tighten the CHECK lines, and give the tests more meaningful names.
This is a continuation of:
http://reviews.llvm.org/rL255555
http://reviews.llvm.org/rL256871
http://reviews.llvm.org/rL256964
http://reviews.llvm.org/rL257400
http://reviews.llvm.org/rL257404
llvm-svn: 257414
|
| |
|
|
|
|
|
| |
There is no reason the value being printed has to be positive.
Fixes pr25802.
llvm-svn: 257412
|
| |
|
|
| |
llvm-svn: 257410
|
| |
|
|
|
|
|
| |
Fix the FIXME added with:
http://reviews.llvm.org/rL257400
llvm-svn: 257404
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Currently we're unrolling loops more in minsize than in optsize, which
means -Oz will have a larger code size than -Os. That doesn't make any
sense.
This resolves the FIXME about this in LoopUnrollPass and extends the
optsize test to make sure we use the smaller threshold for minsize as
well.
llvm-svn: 257402
|
| |
|
|
| |
llvm-svn: 257401
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
calls
This is a continuation of adding FMF to call instructions:
http://reviews.llvm.org/rL255555
The intent of the patch is to preserve the current behavior of the transform except
that we use the sqrt instruction's 'fast' attribute as a trigger rather than the
function-level attribute.
But this raises a bug noted by the new FIXME comment.
In order to do this transform:
sqrt((x * x) * y) ---> fabs(x) * sqrt(y)
...we need all of the sqrt, the first fmul, and the second fmul to be 'fast'.
If any of those ops is strict, we should bail out.
Differential Revision: http://reviews.llvm.org/D15937
llvm-svn: 257400
|
| |
|
|
| |
llvm-svn: 257399
|
| |
|
|
| |
llvm-svn: 257396
|
| |
|
|
| |
llvm-svn: 257395
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Always expect tglobaladdr and texternalsym to be wrapped in
WebAssemblywrapper nodes. Also, split out a regPlusGA from regPlusImm so
that it can special-case global addresses, as they can be folded in more
cases.
Unfortunately this doesn't enable any new optimizations yet due to
SelectionDAG limitations. I'll be submitting changes to the SelectionDAG
infrastructure, along with tests, in a separate patch.
llvm-svn: 257394
|
| |
|
|
|
|
|
| |
The old lowering for uint_to_fp failed opencl conformance.
It might be OK for fast math mode, but I'm not sure.
llvm-svn: 257393
|
| |
|
|
| |
llvm-svn: 257391
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Address review feedback from r255909.
Move body of resolveCycles(bool AllowTemps) to
resolveRecursivelyImpl(bool AllowTemps). Revert resolveCycles back
to asserting on temps, and add new resolveNonTemporaries interface
to invoke the new implementation with AllowTemps=true. Document
the differences between these interfaces, specifically the effect
on RAUW support and uniquing. Call appropriate interface from
ValueMapper.
llvm-svn: 257389
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
deallocated.
When asan is enabled, we poison slabs as we allocate them, and only unpoison the pieces
we need from the slab.
However, in Reset, we were failing to reset the state of the slab back to being poisoned.
Patch by b17 c0de.
llvm-svn: 257388
|
| |
|
|
| |
llvm-svn: 257387
|
| |
|
|
|
|
| |
It might be better to let this be a select failure instead.
llvm-svn: 257386
|
| |
|
|
| |
llvm-svn: 257385
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r254363.
load64BitDebugHelp() has the side effect of loading dbghelp and setting
globals. It should be called in no-asserts builds as well as debug
builds.
llvm_unreachable is also not appropriate here, since we actually want to
return if dbghelp couldn't be loaded in a non-asserts build.
llvm-svn: 257384
|
| |
|
|
|
|
|
|
| |
OrcRemoteTargetClient::ObjectAllocs.
More MSVC bot appeasement.
llvm-svn: 257382
|
| |
|
|
| |
llvm-svn: 257381
|
| |
|
|
|
|
|
|
| |
This removes ifdefs and fixes the build for users of the Win8.0 SDK,
which I happen to be. Upgrading is not hard, but executing the same code
everywhere seems better.
llvm-svn: 257379
|
| |
|
|
| |
llvm-svn: 257377
|
| |
|
|
|
|
|
|
|
|
|
| |
After these revisions, for arm targets, the -mcpu=xscale option caused
an error: "the clang compiler does not support '-mcpu=xscale'". Adding
"v5e" as a SUB_ARCH in ARMTargetParser.def helps.
Submitted by: Andrew Turner
Differential Revision: http://reviews.llvm.org/D16043
llvm-svn: 257376
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes the memory sanitizer origin store instrumentation for
array types. This can be triggered by cases where frontend lowers
function return to array type instead of aggregation.
For instance, the C code:
--
struct mypair {
int64_t x;
int y;
};
mypair my_make_pair(int64_t x, int y) {
mypair p;
p.x = x;
p.y = y;
return p;
}
int foo (int p)
{
mypair z = my_make_pair(p, 0);
return z.y + z.x;
}
--
It will be lowered with target set to aarch64-linux and -O0 to:
--
[...]
define i32 @_Z3fooi(i32 %p) #0 {
[...]
%call = call [2 x i64] @_Z12my_make_pairxi(i64 %conv, i32 0)
%1 = bitcast %struct.mypair* %z to [2 x i64]*
store [2 x i64] %call, [2 x i64]* %1, align 8
[...]
--
The origin store will emit a 'icmp' to test each store value again the
TLS origin array. However since 'icmp' does not support ArrayType the
memory instrumentation phase will bail out with an error.
This patch change it by using the same strategy used for struct type on
array.
It fixes the 'test/msan/insertvalue_origin.cc' for aarch64 (the -O0 case).
llvm-svn: 257375
|
| |
|
|
| |
llvm-svn: 257373
|
| |
|
|
|
|
| |
Yet another attempt to pacify MSVC.
llvm-svn: 257372
|
| |
|
|
|
|
|
|
| |
I'm still seeing GCC ICE locally, but figured I'd throw this at the wall
& see if it sticks for the bots at least. Will continue investigating
the ICE in any case.
llvm-svn: 257367
|
| |
|
|
| |
llvm-svn: 257366
|
| |
|
|
| |
llvm-svn: 257365
|
| |
|
|
|
|
| |
More MSVC bot appeasement.
llvm-svn: 257364
|
| |
|
|
|
|
| |
Another shot at appeasing the clang-x86_64-ubuntu-gdb-75 builder.
llvm-svn: 257362
|
| |
|
|
| |
llvm-svn: 257360
|
| |
|
|
|
|
|
|
|
| |
intermittent XPASSes on some builders.
These can be reinstated when we have proper support for small-code model in
the JIT.
llvm-svn: 257359
|
| |
|
|
| |
llvm-svn: 257358
|
| |
|
|
|
|
|
| |
supported, and only worked previously because we weren't really running them
out-of-process.
llvm-svn: 257355
|
| |
|
|
| |
llvm-svn: 257354
|
| |
|
|
| |
llvm-svn: 257353
|
| |
|
|
|
|
|
|
| |
The hardware instruction's output on 0 is -1 rather than 32.
Eliminate a test and select to -1. This removes an extra instruction
from the compatability function with HSAIL's firstbit instruction.
llvm-svn: 257352
|
| |
|
|
|
|
| |
RemoteTarget.cpp was removed in r257343.
llvm-svn: 257351
|
| |
|
|
|
|
| |
OrcRemoteTargetServer::Allocator.
llvm-svn: 257350
|
| |
|
|
|
|
| |
providing a more helpful error diagnostic.
llvm-svn: 257349
|
| |
|
|
| |
llvm-svn: 257348
|