NAKAMURA Takumi [Tue, 31 Mar 2015 00:03:43 +0000 (00:03 +0000)]
llvm/examples: Suppress building a few JIT examples.
examples/ExceptionDemo/CMakeFiles/ExceptionDemo.dir/ExceptionDemo.cpp.o:(.data.rel.ro._ZTIN4llvm18MCJITMemoryManagerE[_ZTIN4llvm18MCJITMemoryManagerE]+0x10): undefined reference to `typeinfo for llvm::RuntimeDyld::MemoryManager'
The only user of `DebugLoc::getFromDILexicalBlock()` was creating a new
`MDLocation` as convenient API for passing an `MDScope`. Stop doing
that, and remove the API. If in the future we actually *want* to create
new DebugLocs, calling `MDLexicalBlock::get()` makes more sense.
LexicalScopes: Use debug info hierarchy pervasively
Pervasively use the types provided by the debug info hierarchy rather
than `MDNode` in `LexicalScopes`.
I noticed (again, I guess, based on comments in the implementation?)
that `DILexicalBlockFile::getScope()` returns something different from
`DILexicalBlockFile::getContext()`. I created a local helper for
getting the same logic from `MDLexicalBlockFile` called
`getScopeOfScope()`. I still don't really understand it, but I've added
some FIXMEs and I'll come back to it (I suspect the way we encode these
objects isn't really ideal).
Note that my previous commit r233610 accidentally changed behaviour in
`findLexicalScope()` -- it transitioned from a call to
`DILexicalBlockFile::getScope()` to `MDLexicalBlockFile::getScope()`
(sounds right, doesn't it?) -- so I've fixed that as a drive-by. No
tests failed with my error, so it looks like we're missing some coverage
here... when I come back to understand the logic, I'll see if I can add
some.
Other than the fix to `findLexicalScope()`, no functionality change.
David Majnemer [Mon, 30 Mar 2015 22:58:10 +0000 (22:58 +0000)]
[WinEH] Run cleanup handlers when an exception is thrown
Generate tables in the .xdata section representing what actions to take
when an exception is thrown. This currently fills in state for
cleanups, catch handlers are still unfinished.
David Blaikie [Mon, 30 Mar 2015 21:41:43 +0000 (21:41 +0000)]
[opaque pointer type] Change GetElementPtrInst::getIndexedType to take the pointee type
This pushes the use of PointerType::getElementType up into several
callers - I'll essentially just have to keep pushing that up the stack
until I can eliminate every call to it...
Transforms: Update unit tests to use verifyModule()
Since I'm slowly gutting `DISubprogram` and `DICompileUnit`, update the
`CloneFunc` unit tests to call `verifyModule()` (where the checks are
moving to).
Remove old API for `DebugLoc` now that all the callers have been
updated. If this broke your out-of-tree build, here's a quick map from
the old API to the new one:
DebugLoc DebugLoc::getFromMDLocation(MDNode *)
=> DebugLoc::DebugLoc(MDLocation *)
=> explicit DebugLoc::DebugLoc(MDNode *) // works with broken code
MDNode *DebugLoc::getAsMDNode(LLVMContext &)
=> MDLocation *DebugLoc::get()
=> DebugLoc::operator MDLocation *()
=> MDNode *DebugLoc::getAsMDNode() // works with broken code
bool DebugLoc::isUnknown()
=> DebugLoc::operator MDLocation *()
i.e.: if (MDLocation *DL = ...)
=> DebugLoc::operator bool() // works with broken code
i.e.: if (DebugLoc DL = ...)
I've noted above the only functions that won't crash on broken code (due
to downcasting to `MDLocation`). If your code could be dealing with
broken IR (i.e., you haven't run the verifier yet, or you've used a
temporary node that will eventually (but not yet) get RAUW'ed to an
`MDLocation`), you need to restrict yourself to those.
Update lib/IR and lib/Bitcode to use the new `DebugLoc` API. Added an
explicit conversion to `bool` (avoiding a conversion to `MDLocation`),
since a couple of these use cases need to handle broken code.
Paul Robinson [Mon, 30 Mar 2015 19:37:44 +0000 (19:37 +0000)]
Verify 'optnone' can run DAG combiner when appropriate.
Adds a test to verify the behavior that r233153 restored: 'optnone'
does not spuriously disable the DAG combiner, and in fact there are
cases where the DAG combiner must run (even at -O0 or 'optnone') in
order for codegen to succeed.
[NVPTX] Associate a minimum PTX version for each SM architecture
When a new SM architecture is introduced, it is only supported by the
current PTX version and later. Make sure we are using at least the
minimum PTX version for the target architecture.
Kit Barton [Mon, 30 Mar 2015 18:46:15 +0000 (18:46 +0000)]
[PPC] Modify HTM and crypto intrinsics to inherit from GCCBuiltin
There was a change to the way some of the HTM and crypto builtins are being
handled in Clang. Previously, some of the builtins were dealt with in the
CodeGenFunction::EmitPPCBuiltinExpr method (in order to do range checking on
constant arguments). These check will been moved to Sema
http://reviews.llvm.org/D8672), which means those builtins will not be handled
in the EmitPPCBuiltinExpr method anymore. As a result, the definition of the
intrinsics in IntrinsicsPowerPC.td needs to be modified to inherit from the
GCCBuiltin definition.
Rewrite `DebugLoc` with a cleaner API that reflects its current status
as a wrapper around an `MDLocation` pointer.
- Add accessors/constructors to/from `MDLocation`.
- Simplify construction from `MDNode`.
- Remove unnecessary `LLVMContext` from APIs.
- Drop some API that isn't useful any more.
- Rewrite documentation.
Actually, I've left the old API behind temporarily at the bottom of the
class so that I can update callers in separate commits. I'll remove it
once the callers are updated.
Write `MDLocation::getInlinedAtScope()` and use it to re-implement
`DebugLoc::getScopeNode()` (and simplify `DISubprogram::Verify()`).
This follows the inlined-at linked list and returns the scope of the
deepest/last location.
Momentarily (but never in tree), the `scope:` field was called
`parent:`. Apparently a few testcases were left behind with "parent" in
the name, so rename them.
Check operands of `MDSubprogram`s in the verifier, and update the
accessors and factory functions to use more specific types.
There were a lot of broken testcases, which I fixed in r233466. If you
have out-of-tree tests for debug info, you probably need similar changes
to the ones I made there.
Rafael Espindola [Mon, 30 Mar 2015 13:39:16 +0000 (13:39 +0000)]
Special case the creation of relocation sections.
These sections are never looked up and we know when have to create them. Use
that to save adding them to the regular map and avoid a symbol->string->symbol
conversion for the group symbol.
This also makes the implementation independent of the details of how unique
sections are implemented.
Daniel Sanders [Mon, 30 Mar 2015 13:27:25 +0000 (13:27 +0000)]
[mips] Support 9-bit offsets for the 'R' inline assembly memory constraint.
Summary:
The 'R' constraint is actually supposed to be much more complicated than
this and is defined in terms of whether it will cause macro expansion in
the assembler. 'R' is getting less useful due to architecture changes and
ought to be replaced by other constraints. We therefore implement 9-bit
offsets which will work for all subtargets and all instructions.
Craig Topper [Mon, 30 Mar 2015 06:31:11 +0000 (06:31 +0000)]
[X86] Remove FeatureAES for 'corei7' CPU. 'corei7' should match 'nehalem' which doesn't have AES. Having AES and not PCLMUL makes 'corei7' halfway between Nehalem and Westmere.
[MCJIT] In debug memory dump output, don't truncate 64 bit addresses
Summary: In dumpMemorySections a cast was too short, and in resolveRelocations a format string was too short.
Test Plan:
Enable debug build and run a program which invokes MCJIT::finalizeObject(). Saw valid input as below (highlighted addresses were previously truncated):
Lang Hames [Mon, 30 Mar 2015 03:37:06 +0000 (03:37 +0000)]
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
Lang Hames [Sun, 29 Mar 2015 21:55:27 +0000 (21:55 +0000)]
[Orc] Use raw TargetAddresses for callback trampoline addresses, rather than IR.
Add convenience function for building a typed IR Constant from trampoline
addresses.
Akira Hatanaka [Sat, 28 Mar 2015 21:07:24 +0000 (21:07 +0000)]
Delete MCInstPrinter::AvailableFeatures.
All the ports have been fixed to read the feature bits from the subtarget passed
to the print methods. Also, delete the call to setAvailableFeatures in the
constructor of NVPTX's instprinter as the instprinter wasn't using the feature
bits anywhere.
Hal Finkel [Sat, 28 Mar 2015 19:42:41 +0000 (19:42 +0000)]
[PowerPC] Add asm parser support for bitmask forms of rotate-and-mask instructions
The asm syntax for the 32-bit rotate-and-mask instructions can take a 32-bit
bitmask instead of an (mb, me) pair. This syntax is not specified in the Power
ISA manual, but is accepted by GNU as, and is documented in IBM's Assembler
Language Reference. The GNU Multiple Precision Arithmetic Library (gmp)
contains assembly that uses this syntax.
To implement this, I moved the isRunOfOnes utility function from
PPCISelDAGToDAG.cpp to PPCMCTargetDesc.h.
Simon Pilgrim [Sat, 28 Mar 2015 18:31:31 +0000 (18:31 +0000)]
[DAGCombiner] Fixed incorrect test for buildvector of constant integers.
DAGCombiner::ReassociateOps was correctly testing for an constant integer scalar but failed to correctly test for constant integer vectors (it was testing for any constant vector).
Hal Finkel [Sat, 28 Mar 2015 16:44:57 +0000 (16:44 +0000)]
[ConstantFold] Don't fold ppc_fp128 <-> int bitcasts
PPC_FP128 is really the sum of two consecutive doubles, where the first double
is always stored first in memory, regardless of the target endianness. The
memory layout of i128, however, depends on the target endianness, and so we
can't fold this without target endianness information. As a result, we must not
do this folding in lib/IR/ConstantFold.cpp (it could be done instead in
Analysis/ConstantFolding.cpp, but that's not done now).
Akira Hatanaka [Sat, 28 Mar 2015 04:03:51 +0000 (04:03 +0000)]
[SparcInstPrinter] Use the subtarget that is passed to the print function
instead of the one passed to the constructor.
Unfortunately, I don't have a test case for this change. In order to test my
change, I will have to run the code after line 90 in printSparcAliasInstr. I
couldn't make that happen because printAliasInstr would always handle the
printing of fcmp instructions that the code after line 90 is supposed to handle.
Verifier: Allow subroutine types to have no type array
Loosen one check from r233446: as long as `DIBuilder` requires a
non-null type for every subprogram, we should allow a null type array.
Also add tests for the rest of `MDSubroutineType`, which were somehow
missing.
DebugInfo: Fix testcases with invalid MDSubprogram nodes
Fix testcases that don't pass the verifier after a WIP patch to check
`MDSubprogram` operands more effectively. I found the following issues:
- When `isDefinition: false`, the `variables:` field might point at
`!{i32 786468}`, or at a tuple that pointed at an empty tuple with
the comment "previously: invalid DW_TAG_base_type" (I vaguely recall
adding those comments during an upgrade script). In these cases, I
just dropped the array.
- The `variables:` field might point at something like `!{!{!8}}`,
where `!8` was an `MDLocation`. I removed the extra layer of
indirection.
- Invalid `type:` (not an `MDSubroutineType`).
Ahmed Bougacha [Sat, 28 Mar 2015 01:22:37 +0000 (01:22 +0000)]
[CodeGen] "PromoteInteger" f32 to f64 doesn't make sense.
The original f32->f64 promotion logic was refactored into roughly the
currently shape in r37781. However, starting with r132263, the
legalizer has been split into different kinds, and the previous
"Promote" (which did the right thing) was search-and-replace'd into
"PromoteInteger". The divide gradually deepened, with type legalization
("PromoteInteger") being separated from ops legalization
("Promote", which still works for floating point ops).
Fast-forward to today: there's no in-tree target with legal f64 but
illegal f32 (rather: no tests were harmed in the making of this patch).
With such a target, i.e., if you trick the legalizer into going through
the PromoteInteger path for FP, you get the expected brokenness.
For instance, there's no PromoteIntRes_FADD (the name itself sounds
wrong), so we'll just hit some assert in the PromoteInteger path.
Don't pretend we can promote f32 to f64. Instead, always soften.
projects / llvm / log