summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* Use unique_ptr to manage TypePromotionActions owned by TypePromotionTransaction.David Blaikie2014-04-151-28/+19
| | | | llvm-svn: 206250
* Use unique_ptr to manage ownership of GCFunctionInfos in GCStrategyDavid Blaikie2014-04-151-10/+2
| | | | llvm-svn: 206249
* Use unique_ptr for the result of Registry entries.David Blaikie2014-04-152-8/+6
| | | | llvm-svn: 206248
* Use unique_ptr to manage ownership of GCStrategy objects in GCMetadataDavid Blaikie2014-04-152-19/+12
| | | | llvm-svn: 206246
* Use unique_ptr for section/segment ownership in WinCOFFObjectWriterDavid Blaikie2014-04-151-41/+32
| | | | llvm-svn: 206245
* Use unique_ptr to own MCFunctions within MCModule.David Blaikie2014-04-153-12/+12
| | | | | | | | 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
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-1539-505/+512
| | | | | | instead of comparing to nullptr. llvm-svn: 206243
* Use std::unique_ptr to manage MCBasicBlocks in MCFunction.David Blaikie2014-04-152-15/+10
| | | | llvm-svn: 206242
* [MC] Require an MCContext when constructing an MCDisassembler.Lang Hames2014-04-1512-65/+75
| | | | | | | | | | | | | | | | 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
* X86JITInfo: [x86] Use X86CompilationCallback_SSE() along;NAKAMURA Takumi2014-04-151-3/+2
| | | | | | | | | | *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
* [ARM64,C++11]: Range'ify the dead-register-definition pass.Jim Grosbach2014-04-151-27/+23
| | | | | | Range-based for loops. No functional change intended. llvm-svn: 206239
* [MC] Emit an error if cfi_startproc is used before a symbol is defined.Quentin Colombet2014-04-151-0/+4
| | | | | | | | | 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
* [ARM64][MC] Set the default CPU string to generic.Quentin Colombet2014-04-151-3/+1
| | | | llvm-svn: 206228
* Use std::unique_ptr for DIE childrenDavid Blaikie2014-04-145-43/+31
| | | | | | | | | Got bored, removed some manual memory management. Pushed references (rather than pointers) through a few APIs rather than replacing *x with x.get(). llvm-svn: 206222
* X86: Nuke one more CPU autodetect blurb.Jim Grosbach2014-04-141-7/+1
| | | | | | Missed one in r206094. This brings MC and TargetMachine back into sync. llvm-svn: 206220
* Change argument order and add explanatory comment to r206130David Blaikie2014-04-142-9/+9
| | | | | | Changes requested in code review by Eric Christopher of r206130. llvm-svn: 206219
* Use FrameSetup on frame instructions for the Mips port.Eric Christopher2014-04-142-2/+3
| | | | | | | I can't seem to get a testcase to show a difference here, but it's part of the unconditional-br.ll line table weirdness. llvm-svn: 206218
* Revert "Revert r206045, "Fix shift by constants for vector.""Matt Arsenault2014-04-142-16/+34
| | | | | | Fix cases where the Value itself is used, and not the constant value. llvm-svn: 206214
* [ARM64][MC] Set the default CPU to cyclone when initilizating the MC layer.Quentin Colombet2014-04-141-0/+6
| | | | | | | | This matches that ARM64Subtarget does for now. This is related to <rdar://problem/16573920> llvm-svn: 206211
* Re-apply r206096 after investigating the gdb buildbot failure.Adrian Prantl2014-04-141-9/+14
| | | | | | | | | | | | | | | Thanks to dblaikie for updating the testcase! Debug info: (bugfix) C++ C/Dtors can be compiled to multiple functions, therefore, their declaration cannot have one DW_AT_linkage_name. The specific instances however can and should have that attribute. This patch reorders the code in DwarfUnit::getOrCreateSubprogramDIE() to emit linkage names for C/Dtors. rdar://problem/16362674. llvm-svn: 206210
* Fix for codegen bug that could cause illegal cmn instruction generationLouis Gerbarg2014-04-141-1/+16
| | | | | | | | | | | In rare cases the dead definition elimination pass code can cause illegal cmn instructions when it replaces dead registers on instructions that use unmaterialized frame indexes. This patch disables the dead definition optimization for instructions which include frame index operands. rdar://16438284 llvm-svn: 206208
* Add a flag to disable the ARM64DeadRegisterDefinitionsPassLouis Gerbarg2014-04-141-1/+10
| | | | | | | This patch adds a -arm64-dead-def-elimination flag so that it is possible to disable dead definition elimination. Includes test case. llvm-svn: 206207
* [ARM64] Port over missing subtarget features, and CPU definitions from AArch64.James Molloy2014-04-143-5/+52
| | | | llvm-svn: 206198
* [ARM64] Add big endian target arm64_be.James Molloy2014-04-141-1/+9
| | | | llvm-svn: 206197
* Replace two calls to object::symbol_iterator::increment(), which hadKaelyn Takata2014-04-141-10/+4
| | | | | | been removed in r200442. llvm-svn: 206196
* Remove a variable from r206192 that is only used in an assert.Kaelyn Takata2014-04-141-2/+2
| | | | llvm-svn: 206195
* Fix a bug in which BranchProbabilityInfo wasn't setting branch weights of ↵Akira Hatanaka2014-04-141-0/+3
| | | | | | | | | | | | basic blocks inside loops correctly. Previously, BranchProbabilityInfo::calcLoopBranchHeuristics would determine the weights of basic blocks inside loops even when it didn't have enough information to estimate the branch probabilities correctly. This patch fixes the function to exit early if it doesn't see any exit edges or back edges and let the later heuristics determine the weights. This fixes PR18705 and <rdar://problem/15991090>. Differential Revision: http://reviews.llvm.org/D3363 llvm-svn: 206194
* Fix up MCFixup::getAccessVariant to handle unary expressions.Kaelyn Takata2014-04-141-1/+6
| | | | | | | | | | | | This allows correct relocations to be generated for a symbolic address that is being adjusted by a negative constant. Since r204294, such expressions have triggered undefined behavior when LLVM was built without assertions. Credit goes to Rafael for this patch; I'm submitting it on his behalf as he is on vacation this week. llvm-svn: 206192
* [mips] Fix fcopysign for MIPS-IV and add the test.Daniel Sanders2014-04-141-1/+1
| | | | | | | | | | | | | | | Summary: This was another incorrect use of hasMips64() vs isGP64bit(). Depends on D3344 Reviewers: matheusalmeida, vmedic Reviewed By: vmedic Differential Revision: http://reviews.llvm.org/D3347 llvm-svn: 206187
* [mips] Fix more incorrect uses of HasMips64 and isMips64()Daniel Sanders2014-04-144-13/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: - Conditional moves acting on 64-bit GPR's should require MIPS-IV rather than MIPS64 - ISD::MUL, and ISD::MULH[US] should be lowered on all 64-bit ISA's Patch by David Chisnall His work was sponsored by: DARPA, AFRL I've added additional testcases to cover as much of the codegen changes affecting MIPS-IV as I can. Where I've been unable to find an existing MIPS64 testcase that can be re-used for MIPS-IV (mainly tests covering ISD::GlobalAddress and similar), I at least agree that MIPS-IV should behave like MIPS64. Further testcases that are fixed by this patch will follow in my next commit. The testcases from that commit that fail for MIPS-IV without this patch are: LLVM :: CodeGen/Mips/2010-07-20-Switch.ll LLVM :: CodeGen/Mips/cmov.ll LLVM :: CodeGen/Mips/eh-dwarf-cfa.ll LLVM :: CodeGen/Mips/largeimmprinting.ll LLVM :: CodeGen/Mips/longbranch.ll LLVM :: CodeGen/Mips/mips64-f128.ll LLVM :: CodeGen/Mips/mips64directive.ll LLVM :: CodeGen/Mips/mips64ext.ll LLVM :: CodeGen/Mips/mips64fpldst.ll LLVM :: CodeGen/Mips/mips64intldst.ll LLVM :: CodeGen/Mips/mips64load-store-left-right.ll LLVM :: CodeGen/Mips/sint-fp-store_pattern.ll Reviewers: dsanders Reviewed By: dsanders CC: matheusalmeida Differential Revision: http://reviews.llvm.org/D3343 llvm-svn: 206183
* Teach llvm-lto to respect the given RelocModel.James Molloy2014-04-141-1/+5
| | | | | | Patch by Nick Tomlinson! llvm-svn: 206177
* ARM64: remove buggy REV16 pattern.Tim Northover2014-04-141-2/+1
| | | | | | The 32-bit pattern is still valid: 0123 -> 3210 -> 1032. llvm-svn: 206172
* AArch64/ARM64: enable directcond.ll test on ARM64.Tim Northover2014-04-141-0/+2
| | | | | | | Code change is because optimizeCompareInstr didn't know how to pull the condition code out of FCSEL instructions. llvm-svn: 206171
* ARM64: add patterns for csXYZ with reversed operands.Tim Northover2014-04-141-0/+13
| | | | | | | AArch64 tests for this, and it's obviously a good idea. Have to invert the condition code, of course. llvm-svn: 206170
* ARM64: add support for AArch64's addsub_ext.llTim Northover2014-04-141-1/+1
| | | | | | | | | There was one definite issue in ARM64 (the off-by-1 check for whether a shift could be folded in) and one difference that is probably correct: ARM64 didn't fold nodes with multiple uses into the arithmetic operations unless optimising for code size. llvm-svn: 206168
* ARM64: optimise (cmp x, (sub 0, y)) to (cmn x, y).Tim Northover2014-04-141-11/+30
| | | | | | | This transformation is only valid when being used for an EQ or NE comparison since the flags change otherwise. llvm-svn: 206167
* [XCore] Don't create invalid MKMSK instructions inside loadImmediate().Richard Osborne2014-04-141-1/+9
| | | | | | | | | | | | | | | | | Summary: Previously loadImmediate() would produce MKMSK instructions with invalid immediate values such as mkmsk r0, 9. Fix this by checking the mask size is valid. Reviewers: robertlytton Reviewed By: robertlytton CC: llvm-commits Differential Revision: http://reviews.llvm.org/D3289 llvm-svn: 206163
* Whitespace.NAKAMURA Takumi2014-04-141-1/+0
| | | | llvm-svn: 206154
* Revert r206045, "Fix shift by constants for vector."NAKAMURA Takumi2014-04-142-23/+13
| | | | | | It broke some builders, at least, i686. llvm-svn: 206153
* [Allocator] Hoist the external helper function into a namespace scopeChandler Carruth2014-04-141-0/+4
| | | | | | | declaration. GCC 4.7 appears to get hopelessly confused by declaring this function within a member function of a class template. Go figure. llvm-svn: 206152
* Don't assert in BasicTTI::getMemoryOpCost for non-simple typesHal Finkel2014-04-141-6/+8
| | | | | | | | BasicTTI::getMemoryOpCost must explicitly check for non-simple types; setting AllowUnknown=true with TLI->getSimpleValueType is not sufficient because, for example, non-power-of-two vector types return non-simple EVTs (not MVT::Other). llvm-svn: 206150
* [Allocator] Make the underlying allocator a template instead of anChandler Carruth2014-04-142-26/+11
| | | | | | | | | | | | abstract interface. The only user of this functionality is the JIT memory manager and it is quite happy to have a custom type here. This removes a virtual function call and a lot of unnecessary abstraction from the common case where this is just a *very* thin vaneer around a call to malloc. Hopefully still no functionality changed here. =] llvm-svn: 206149
* [Allocator] Switch the BumpPtrAllocator to use a vector of pointers toChandler Carruth2014-04-142-31/+11
| | | | | | | | | | | | | | | | | | | | | | | slabs rather than embedding a singly linked list in the slabs themselves. This has a few advantages: - Better utilization of the slab's memory by not wasting 16-bytes at the front. - Simpler allocation strategy by not having a struct packed at the front. - Avoids paging every allocated slab in just to traverse them for deallocating or dumping stats. The latter is the really nice part. Folks have complained from time to time bitterly that tearing down a BumpPtrAllocator, even if it doesn't run any destructors, pages in all of the memory allocated. Now it won't. =] Also resolves a FIXME with the scaling of the slab sizes. The scaling now disregards specially sized slabs for allocations larger than the threshold. llvm-svn: 206147
* Use APInt arithmetic, fixed typo. Thanks to Benjamin Kramer for noticing that.Serge Pavlov2014-04-141-2/+2
| | | | llvm-svn: 206144
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-1493-1017/+1025
| | | | | | instead of comparing to nullptr. llvm-svn: 206142
* [PowerPC] [Constant Hoisting] Enable constant hoisting on PPCHal Finkel2014-04-131-0/+147
| | | | | | | | | | Implements the various TTI functions to enable constant hoisting on PPC. The only significant test-suite change is this: MultiSource/Benchmarks/VersaBench/bmm/bmm - 20% speedup (which essentially reverses the slowdown from r206120). llvm-svn: 206141
* MC: check machine magic when applying offset adjustmentsSaleem Abdulrasool2014-04-131-2/+4
| | | | | | | | | | | | | | | The values for the relocation type can (and do) overlap across various architectures. When performing an adjustment of the emitted relocation in the final object file, check that the file magic matches the target for which the relocation type is valid (e.g. a I386 relocation is only applied to an X86 object file, and an AMD64 relocation is only applied to an X86_64 object file). This was noticed while adding support for ARM WinCOFF object file emission. A test case for this is not really possible as the values for REL32 do not overlap on I386 and AMD64, which is why this was never noticed in practice. The ARM WinCOFF emission is not yet ready to merge into the tree. llvm-svn: 206138
* Recognize test for overflow in integer multiplication.Serge Pavlov2014-04-131-0/+240
| | | | | | | | | | | | | | | | | | If multiplication involves zero-extended arguments and the result is compared as in the patterns: %mul32 = trunc i64 %mul64 to i32 %zext = zext i32 %mul32 to i64 %overflow = icmp ne i64 %mul64, %zext or %overflow = icmp ugt i64 %mul64 , 0xffffffff then the multiplication may be replaced by call to umul.with.overflow. This change fixes PR4917 and PR4918. Differential Revision: http://llvm-reviews.chandlerc.com/D2814 llvm-svn: 206137
* [PowerPC] Fix rlwimi isel when mask is not constantHal Finkel2014-04-131-1/+8
| | | | | | | | | | | | | | | | | We had been using the known-zero values of the operand of the or to construct the mask for an rlwimi; this is not quite correct, but fine when the mask is constant. When the mask is constant, then the known zeros of the operand must be a superset of the zeros in the mask. However, when the mask is not a constant, then there might be bits in the operand that are not known to be zero that, at runtime, might be zero in the mask. Therefore, we check that any bits not known to be zero *are* known to be one in the mask. Otherwise, we can't fold the mask with the or and shift. This was revealed as a miscompile of MultiSource/Benchmarks/BitBench/drop3/drop3 when I started experimenting with constant hoisting. llvm-svn: 206136
* Fix instruction debug info location during legalizationDavid Blaikie2014-04-132-16/+13
| | | | | | | | | | | | I found this from a particular GDB test suite case of inlining (something similar is provided as a test case) but came across a few other related cases (other callers of the same functions, and one other instance of the same coding mistake in a separate function). I'm not sure what the best way to test this is (let alone to cover the other cases I discovered), so hopefully this sufficies - open to ideas. llvm-svn: 206130
OpenPOWER on IntegriCloud