| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
Fixup after r206300.
<rdar://problem/15500563>
llvm-svn: 206305
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement DebugInfoVerifier, which steals verification relying on
DebugInfoFinder from Verifier.
- Adds LegacyDebugInfoVerifierPassPass, a ModulePass which wraps
DebugInfoVerifier. Uses -verify-di command-line flag.
- Change verifyModule() to invoke DebugInfoVerifier as well as
Verifier.
- Add a call to createDebugInfoVerifierPass() wherever there was a
call to createVerifierPass().
This implementation as a module pass should sidestep efficiency issues,
allowing us to turn debug info verification back on.
<rdar://problem/15500563>
llvm-svn: 206300
|
| |
|
|
|
|
|
|
|
| |
Split out assertion and output helpers from Verifier in preparation for
writing the DebugInfoVerifier.
<rdar://problem/15500563>
llvm-svn: 206299
|
| |
|
|
| |
llvm-svn: 206297
|
| |
|
|
|
|
| |
managed by k_Memory itself.
llvm-svn: 206293
|
| |
|
|
|
|
| |
temporary Operands.
llvm-svn: 206292
|
| |
|
|
|
|
| |
No code changes for this bunch, just some test rejigs.
llvm-svn: 206291
|
| |
|
|
| |
llvm-svn: 206290
|
| |
|
|
|
|
|
|
| |
Sometimes we need emit the bits that would actually be a MOVN when producing a
relocated MOVZ instruction (don't ask). But not always, a check which ARM64 got
wrong until now.
llvm-svn: 206289
|
| |
|
|
|
|
|
| |
I've left the MachO CodeGen as it is, there's a reasonable chance it should use
the GOT like ConstPools, but I'm not certain.
llvm-svn: 206288
|
| |
|
|
| |
llvm-svn: 206287
|
| |
|
|
|
|
|
| |
This brings it into line with the AArch64 behaviour and should open the way for
certain OpenCL features.
llvm-svn: 206286
|
| |
|
|
|
|
|
|
| |
Code is mostly copied directly across, with a slight extension of the
ISelDAGToDAG function so that it can cope with the floating-point constants
being behind a litpool.
llvm-svn: 206285
|
| |
|
|
| |
llvm-svn: 206284
|
| |
|
|
|
|
|
|
|
|
|
| |
ARM64 suffered multiple -verify-machineinstr failures (principally over the
xsp/xzr issue) because FastISel was completely ignoring which subset of the
general-purpose registers each instruction required.
More fixes are coming in ARM64 specific FastISel, but this should cover the
generic problems.
llvm-svn: 206283
|
| |
|
|
| |
llvm-svn: 206282
|
| |
|
|
| |
llvm-svn: 206281
|
| |
|
|
| |
llvm-svn: 206279
|
| |
|
|
|
|
| |
http://reviews.llvm.org/D3328
llvm-svn: 206276
|
| |
|
|
|
|
| |
CodeGenOnly defined instructions and post matcher expansion methods to emit real instructions add with immediate. However, they can directly alias add with immediate instruction and remove unnecessary definitions and code in MipsAsmParser.cpp. This patch makes no change in functionality, just removes unnecessary definitions and code.
llvm-svn: 206272
|
| |
|
|
| |
llvm-svn: 206271
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by removing the MallocSlabAllocator entirely and just using
MallocAllocator directly. This makes all off these allocators expose and
utilize the same core interface.
The only ugly part of this is that it exposes the fact that the JIT
allocator has no real handling of alignment, any more than the malloc
allocator does. =/ It would be nice to fix both of these to support
alignments, and then to leverage that in the BumpPtrAllocator to do less
over allocation in order to manually align pointers. But, that's another
patch for another day. This patch has no functional impact, it just
removes the somewhat meaningless wrapper around MallocAllocator.
llvm-svn: 206267
|
| |
|
|
| |
llvm-svn: 206266
|
| |
|
|
|
|
|
|
|
|
|
|
| |
allocation libraries, may allow more efficient allocation and
deallocation. It at least makes the interface implementable by the JIT
memory manager.
However, this highlights problematic overloading between the void* and
the T* deallocation functions. I'm looking into a better way to do this,
but as it happens, it comes up rarely in the codebase.
llvm-svn: 206265
|
| |
|
|
|
|
| |
called for SSE-enabled code generator, even if LLVM is not built with -msse.
llvm-svn: 206261
|
| |
|
|
|
|
|
|
|
|
| |
overloads. This doesn't matter *that* much yet, but it will in
a subsequent patch. I had tested the original pattern, but not my
attempt to pacify MSVC. This at least appears to work. Still fixing the
rest of the fallout in the final patch that uses these overloads, but it
will follow shortly.
llvm-svn: 206259
|
| |
|
|
| |
llvm-svn: 206257
|
| |
|
|
|
|
|
|
|
|
| |
'sizeof(T)' for T == void and produces a hard error. I cannot fathom why
this is OK. Oh well. switch to an explicit test for being the
(potentially qualified) void type, which is the only specific case I was
worried about. Hopefully this survives the libstdc++ build bots which
have limited type traits implementations...
llvm-svn: 206256
|
| |
|
|
|
|
| |
its own tree containing FixedStackPseudoSourceValue (which you can use isa/dyn_cast on) and MipsCallEntry (which you can't). Anything that needs to use either a PseudoSourceValue* and Value* is strongly encouraged to use a MachinePointerInfo instead.
llvm-svn: 206255
|
| |
|
|
|
|
| |
instead of comparing to nullptr.
llvm-svn: 206254
|
| |
|
|
|
|
| |
shortly.
llvm-svn: 206253
|
| |
|
|
|
|
| |
instead of comparing to nullptr.
llvm-svn: 206252
|
| |
|
|
|
|
|
|
|
|
|
| |
to types which we can compute the size of. The comparison with zero
isn't actually interesting here, it's mostly about putting sizeof into
a sfinae context.
This is particular important for Deallocate as otherwise the void*
overload can quickly become ambiguous.
llvm-svn: 206251
|
| |
|
|
| |
llvm-svn: 206250
|
| |
|
|
| |
llvm-svn: 206249
|
| |
|
|
| |
llvm-svn: 206248
|
| |
|
|
| |
llvm-svn: 206246
|
| |
|
|
| |
llvm-svn: 206245
|
| |
|
|
|
|
|
|
| |
MCModule's ctor had to be moved out of line so the definition of
MCFunction was available. (ctor requires the dtor of members (in case
the ctor throws) which required access to the dtor of MCFunction)
llvm-svn: 206244
|
| |
|
|
|
|
| |
instead of comparing to nullptr.
llvm-svn: 206243
|
| |
|
|
| |
llvm-svn: 206242
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch re-introduces the MCContext member that was removed from
MCDisassembler in r206063, and requires that an MCContext be passed in at
MCDisassembler construction time. (Previously the MCContext member had been
initialized in an ad-hoc fashion after construction). The MCCContext member
can be used by MCDisassembler sub-classes to construct constant or
target-specific MCExprs.
This patch updates disassemblers for in-tree targets, and provides the
MCRegisterInfo instance that some disassemblers were using through the
MCContext (previously those backends were constructing their own
MCRegisterInfo instances).
llvm-svn: 206241
|
| |
|
|
|
|
|
|
|
|
| |
*not* Subtarget->hasSSE1()
*but* __SSE__, the flag that LLVM libraries are compiled
The callback calls internal LLVM JIT libraries. It may be built with -msse (or above).
FIXME: JIT may use "host" instead of "generic" by default.
llvm-svn: 206240
|
| |
|
|
|
|
| |
Range-based for loops. No functional change intended.
llvm-svn: 206239
|
| |
|
|
| |
llvm-svn: 206238
|
| |
|
|
|
|
|
|
|
| |
Currently, we bind those directives with the last symbol, so if none
has been defined, this would lead to a crash of the compiler.
<rdar://problem/15939159>
llvm-svn: 206236
|
| |
|
|
|
|
| |
<rdar://problem/16582185>
llvm-svn: 206235
|
| |
|
|
|
|
|
|
|
|
|
|
| |
along with templated overloads much like we have for Allocate. These
will facilitate switching the Deallocate interface of all the Allocator
classes to accept the size by pre-filling it from the type size where we
can do so. I plan to convert several uses to the template variants in
subsequent patches prior to adding the Size parameter.
No functionality changed, WIP.
llvm-svn: 206230
|
| |
|
|
| |
llvm-svn: 206228
|
| |
|
|
|
|
|
| |
static_assert added in r206225. I'm looking into a proper fix, but
wanted the bots back.
llvm-svn: 206226
|