| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 257399
|
| |
|
|
| |
llvm-svn: 257396
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
It might be better to let this be a select failure instead.
llvm-svn: 257386
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 257366
|
| |
|
|
| |
llvm-svn: 257365
|
| |
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 257348
|
| |
|
|
|
|
| |
This is the same as the default expansion.
llvm-svn: 257346
|
| |
|
|
| |
llvm-svn: 257345
|
| |
|
|
| |
llvm-svn: 257344
|
| |
|
|
|
|
|
|
| |
The new ORC remote-JITing support provides a superset of the old code's
functionality, so we can replace the old stuff. As a bonus, a couple of
previously XFAILed tests have started passing.
llvm-svn: 257343
|
| |
|
|
| |
llvm-svn: 257340
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
It actually takes an offset into the current PC-region.
This fixes the 'expr' command in lldb.
Reviewers: vkalintiris, jaydeep, bhushan
Subscribers: dsanders, llvm-commits
Differential Revision: http://reviews.llvm.org/D16054
llvm-svn: 257339
|
| |
|
|
| |
llvm-svn: 257338
|
| |
|
|
| |
llvm-svn: 257337
|
| |
|
|
| |
llvm-svn: 257336
|
| |
|
|
|
|
|
| |
In the OptimizeLEA pass keep instructions' positions in the basic block saved and use them for calculation of the distance between two instructions instead of std::distance. This reduces complexity of the pass from O(n^3) to O(n^2) and thus the compile time.
Differential Revision: http://reviews.llvm.org/D15692
llvm-svn: 257328
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is a recommit of r257253 which was reverted in r257270.
Previous testcase can make failure on some targets due to using opt with O3 option.
Original Summary:
Merge MBBICommon and MBBI's MMOs.
Differential Revision: http://reviews.llvm.org/D15990
llvm-svn: 257317
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds utilities to ORC for managing a remote JIT target. It consists
of:
1. A very primitive RPC system for making calls over a byte-stream. See
RPCChannel.h, RPCUtils.h.
2. An RPC API defined in the above system for managing memory, looking up
symbols, creating stubs, etc. on a remote target. See OrcRemoteTargetRPCAPI.h.
3. An interface for creating high-level JIT components (memory managers,
callback managers, stub managers, etc.) that operate over the RPC API. See
OrcRemoteTargetClient.h.
4. A helper class for building servers that can handle the RPC calls. See
OrcRemoteTargetServer.h.
The system is designed to work neatly with the existing ORC components and
functionality. In particular, the ORC callback API (and consequently the
CompileOnDemandLayer) is supported, enabling lazy compilation of remote code.
Assuming this doesn't trigger any builder failures, a follow-up patch will be
committed which tests these utilities by using them to replace LLI's existing
remote-JITing demo code.
llvm-svn: 257305
|
| |
|
|
| |
llvm-svn: 257304
|
| |
|
|
|
|
| |
the upcoming remote-target support classes.
llvm-svn: 257302
|
| |
|
|
| |
llvm-svn: 257301
|
| |
|
|
|
|
| |
multiclasses. They weren't used and there were extra spaces in the asm string to prepare for the concatenations of the round string that wasn't ever used.
llvm-svn: 257300
|
| |
|
|
|
|
| |
strings.
llvm-svn: 257299
|
| |
|
|
| |
llvm-svn: 257298
|
| |
|
|
|
|
|
| |
These will be used by an upcoming patch that adds remote-jit support utilities
to ORC.
llvm-svn: 257297
|
| |
|
|
|
|
|
|
| |
This is a more generic version of the MCJITMemoryManager::notifyObjectLoaded
method: It provides only a RuntimeDyld reference (rather than an
ExecutionEngine), and so can be used with ORC JIT stacks.
llvm-svn: 257296
|
| |
|
|
| |
llvm-svn: 257295
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
RuntimeDyld::MemoryManager.
The RuntimeDyld::MemoryManager::reserveAllocationSpace method is called when
object files are loaded, and gives clients a chance to pre-allocate memory for
all segments. Previously only the size of each segment (code, ro-data, rw-data)
was supplied but not the alignment. This hasn't caused any problems so far, as
most clients allocate via the MemoryBlock interface which returns page-aligned
blocks. Adding alignment arguments enables finer grained allocation while still
satisfying alignment restrictions.
llvm-svn: 257294
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In r255760, I optimized the SectionMemoryManager to make better use
of virtual memory on platforms where the allocation granularity was
bigger than the protection granularity. As part of this, fixing up
the free list became more complicated and was moved into
`applyMemoryGroupPermissions`. Unfortunately, I forgot to actually
remove the call that drops the free list for RO memory (I did
remove the corresponding one for RX memory), defeating the whole
optimization.
llvm-svn: 257293
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Use proper dataflow ordering to speed convergence.
This will converge the testcase on bug 26055 in 2 iterations.
(data structures speedups to come to make even that faster)
Reviewers: kcc, samsonov, echristo, dblaikie, tvvikram
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16039
llvm-svn: 257292
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Optimized sitofp i64 %x to double. The current sequence
movl %ecx, 8(%esp)
movl %edx, 12(%esp)
fildll 8(%esp)
is replaced with:
movd %ecx, %xmm0
movd %edx, %xmm1
punpckldq %xmm1, %xmm0
movq %xmm0, 8(%esp)
Differential Revision: http://reviews.llvm.org/D15946
llvm-svn: 257285
|
| |
|
|
|
|
| |
Differential Revision:http://reviews.llvm.org/D15955
llvm-svn: 257283
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
JumpThreading's runOnFunction is supposed to return true if it made any
changes. JumpThreading has a call to removeUnreachableBlocks which may
result in changes to the IR but runOnFunction didn't appropriate account
for this possibility, leading to badness.
While we are here, make sure to call LazyValueInfo::eraseBlock in
removeUnreachableBlocks; JumpThreading preserves LVI.
This fixes PR26096.
llvm-svn: 257279
|
| |
|
|
| |
llvm-svn: 257278
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a fix of D13718. D13718 was committed but then reverted because of the following bug:
https://llvm.org/bugs/show_bug.cgi?id=25299
This patch fixes the issue shown in the bug.
Reviewers: majnemer, reames
Subscribers: jevinskie, llvm-commits
Differential Revision: http://reviews.llvm.org/D14308
llvm-svn: 257277
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The code was simply ensuring that the catchpad's pred is its catchswitch,
which was letting cases slip through where the flow edge was the unwind
edge of the catchswitch rather than one of its catch clauses.
Reviewers: andrew.w.kaylor, rnk, majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16011
llvm-svn: 257275
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Funclet-based EH personalities/tables likely can't handle these, and they
can't be generated at source, so make them officially illegal in IR as
well.
Reviewers: andrew.w.kaylor, rnk, majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15963
llvm-svn: 257274
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
A funclet EH pad may be exited by an unwind edge, which may be a
cleanupret exiting its cleanuppad, an invoke exiting a funclet, or an
unwind out of a nested funclet transitively exiting its parent. Funclet
EH personalities require all such exceptional exits from a given funclet to
have the same unwind destination, and EH preparation / state numbering /
table generation implicitly depends on this. Formalize it as a rule of
the IR in the LangRef and verifier.
Reviewers: rnk, majnemer, andrew.w.kaylor
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15962
llvm-svn: 257273
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Funclet EH personalities require a tree-like nesting among funclets
(enforced by the ParentPad linkage in the IR), and also require that
unwind edges conform to certain rules with respect to the tree:
- An unwind edge may exit 0 or more ancestor pads
- An unwind edge must enter exactly one EH pad, which must be distinct
from any exited pads
- A cleanupret's edge must exit its cleanuppad
Describe these rules in the LangRef, and enforce them in the verifier.
Reviewers: rnk, majnemer, andrew.w.kaylor
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15961
llvm-svn: 257272
|
| |
|
|
| |
llvm-svn: 257271
|
| |
|
|
|
|
| |
This reverts commit 1ff11017d2669b933b29fcbb6451cfcda34ad693.
llvm-svn: 257270
|
| |
|
|
|
|
|
|
| |
AVX1 v8i32/v4i64 shuffles are bitcasted to v8f32/v4f64, this patch peeks through any bitcast to check for a load node to allow broadcasts to occur.
This is a re-commit of r257055 after r257264 fixed 32-bit broadcast loads of i64 scalars.
llvm-svn: 257266
|