| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 257329
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 257327
|
| |
|
|
|
|
|
|
|
| |
Covers significantly more code in the template template pack argument
test and fixes the resulting assert problem.
Differential Revision: http://reviews.llvm.org/D15743
llvm-svn: 257326
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r257257 change the way clang-format enforces line breaks after a
templated type has been line-wrapped. This was to fix an incorrect line
break if BinPackParameters is set to false. However, it also leads to
an unwanted line break in a different case. Thus, for now, only do this
when BinPackParameters is false. This isn't ideal yet, but helps us
until we have a better solution.
With BinPackParameters:
Before:
void fffffffffff(aaaaaaaaaaaaaaaaaaaaaaaaaaa<aaaaaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaa> aaaaaaaaaa);
After:
void fffffffffff(
aaaaaaaaaaaaaaaaaaaaaaaaaaa<aaaaaaaaaaaaaaaaaaaaaaa, aaaaaaaaaa>
aaaaaaaaaa);
llvm-svn: 257325
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
return [
aaaaaaaaaaaaaaaaaaaaaa
].aaaaaaa(function() {
//
})
.bbbbbb();
After:
return [aaaaaaaaaaaaaaaaaaaaaa]
.aaaaaaa(function() {
//
})
.bbbbbb();
llvm-svn: 257324
|
| |
|
|
|
|
|
| |
The test hangs/crashes/fails because it does not use the listener API in a way that LLDB expects.
I don't really know if this is the fault of LLDB of the test...
llvm-svn: 257323
|
| |
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D15533
llvm-svn: 257322
|
| |
|
|
| |
llvm-svn: 257321
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
google-runtime-memset no longer issues a warning if the fill char value
is known to be an invalid fill char count.
Namely, it no longer warns for these:
memset(p, 0, 0);
memset(p, -1, 0);
In both cases, swapping the last two args would either be useless (there is
no actual bug) or wrong (it would introduce a bug).
Patch by Matt Armstrong!
llvm-svn: 257320
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
On linux we need the process to give us special permissions before we can attach to it.
Previously, the code for this was copied into every file that needed it. This moves the code to a
central place to reduce code duplication.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15992
llvm-svn: 257319
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
visited decls.
Due to redeclarations, the function may have different declarations used
in CallExpr and in the definition. However, we need to use a unique
declaration for both store and lookup in VisitedCallees. This patch
fixes issues with analysis in topological order. A simple test is
included.
Patch by Alex Sidorin!
Differential Revision: http://reviews.llvm.org/D15410
llvm-svn: 257318
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
non-template base class.
Hopefully this should fix the issues with the windows bots arrising from
r257305.
llvm-svn: 257316
|
| |
|
|
|
|
|
|
| |
allows x86 to use 56 total bits made up of a 32-bit, 16-bit, and 8-bit table. Previously we were using 64 total bits.
This saves 14K from the x86 table size. And saves space on other targets as well.
llvm-svn: 257315
|
| |
|
|
|
|
| |
to prevent ending an array with a comma. But that's perfectly legal and not something we need to prevent. NFC
llvm-svn: 257314
|
| |
|
|
| |
llvm-svn: 257313
|
| |
|
|
|
|
| |
around MSVC's C2783 error.
llvm-svn: 257312
|
| |
|
|
| |
llvm-svn: 257311
|
| |
|
|
|
|
|
|
| |
Process::getPageSize() - the former is redundant.
NFC.
llvm-svn: 257310
|
| |
|
|
|
|
| |
which was removed in r257306.
llvm-svn: 257309
|
| |
|
|
| |
llvm-svn: 257308
|
| |
|
|
|
|
| |
This should fix the modules builder.
llvm-svn: 257307
|
| |
|
|
|
|
| |
broke the windows bots.
llvm-svn: 257306
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 257303
|
| |
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 257291
|
| |
|
|
|
|
|
|
|
|
|
| |
definition of nested class would confuse the context.
llvm\unittests\ExecutionEngine\Orc\ObjectLinkingLayerTest.cpp(115) : error C2327: 'llvm::OrcExecutionTest::TM' : is not a type name, static, or enumerator
llvm\unittests\ExecutionEngine\Orc\ObjectLinkingLayerTest.cpp(115) : error C2065: 'TM' : undeclared identifier
FYI, "this->TM" was valid even before moving class SectionMemoryManagerWrapper.
llvm-svn: 257290
|
| |
|
|
|
|
| |
MSVC18 seems to have other problems here, just hardcode uintptr_t.
llvm-svn: 257289
|
| |
|
|
|
|
|
|
| |
MSVC seems to have problems looking up Value inside of the template. Not
really sure whether that's a bug there or Clang and GCC being too
permissive.
llvm-svn: 257288
|
| |
|
|
|
|
| |
No functional change intended.
llvm-svn: 257287
|
| |
|
|
| |
llvm-svn: 257286
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
type.
This makes it easy and safe to use a set of flags as one elmenet of
a tagged union with pointers. There is quite a bit of code that has
historically done this by casting arbitrary integers to "pointers" and
assuming that this was safe and reliable. It is neither, and has started
to rear its head by triggering safety asserts in various abstractions
like PointerLikeTypeTraits when the integers chosen are invariably poor
choices for *some* platform and *some* situation. Not to mention the
(hopefully unlikely) prospect of one of these integers actually getting
allocated!
With this, it will be straightforward to build type safe abstractions
like this without being error prone. The abstraction itself is also
remarkably simple thanks to the implicit conversion.
This use case and pattern was also independently created by the folks
working on Swift, and they're going to incrementally add any missing
functionality they find.
Differential Revision: http://reviews.llvm.org/D15844
llvm-svn: 257284
|
| |
|
|
|
|
| |
Differential Revision:http://reviews.llvm.org/D15955
llvm-svn: 257283
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a much more general and powerful form of PointerUnion. It
provides a reasonably complete sum type (from type theory) for
pointer-like types. It has several significant advantages over the
existing PointerUnion infrastructure:
1) It allows more than two pointer types to participate without awkward
nesting structures.
2) It directly exposes the tag so that it is convenient to write
switches over the possible members.
3) It can re-use the same type for multiple tag values, something that
has been worked around by either abusing PointerIntPair or defining
nonce types and doing unsafe pointer casting.
4) It supports customization of the PointerLikeTypeTraits used for
specific member types. This means it could (in theory) be used even
with types that are over-aligned on allocation to expose larger
numbers of bits to the tag.
All in all, I think it is at least complimentary to the existing
infrastructure, and a strict improvement for some use cases.
Differential Revision: http://reviews.llvm.org/D15843
llvm-svn: 257282
|
| |
|
|
|
|
| |
have been stored directly in a union for some time. NFC
llvm-svn: 257281
|
| |
|
|
| |
llvm-svn: 257280
|