summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* Don't call addFrameMove on XCore.Rafael Espindola2013-05-161-34/+0
| | | | | | | | getExceptionHandlingType is not ExceptionHandling::DwarfCFI on xcore, so etFrameInstructions is never called. There is no point creating cfi instructions if they are never used. llvm-svn: 181979
* Respect the 'nobuiltin' attribute when determining if a call is to a memory ↵Richard Smith2013-05-161-0/+3
| | | | | | builtin. llvm-svn: 181978
* Removed dead code.Rafael Espindola2013-05-161-8/+4
| | | | llvm-svn: 181975
* Patch number 2 for mips16/32 floating point interoperability stubs.Reed Kotler2013-05-161-3/+43
| | | | | | | | | This creates stubs that help Mips32 functions call Mips16 functions which have floating point parameters that are normally passed in floating point registers. llvm-svn: 181972
* Revert "Support unaligned load/store on more ARM targets"Derek Schuff2013-05-151-17/+4
| | | | | | This reverts r181898. llvm-svn: 181944
* Remove dead code.Eli Bendersky2013-05-151-17/+0
| | | | | | This method is not being used/tested anywhere. llvm-svn: 181943
* LoopVectorize: Move call of canHoistAllLoads to canVectorizeWithIfConvertArnold Schwaighofer2013-05-151-4/+4
| | | | | | | | | We only want to check this once, not for every conditional block in the loop. No functionality change (except that we don't perform a check redudantly anymore). llvm-svn: 181942
* Delete dead code.Rafael Espindola2013-05-151-19/+9
| | | | llvm-svn: 181941
* undef setjmp in PPCCTRLoopsHal Finkel2013-05-151-0/+16
| | | | | | | Trying to unbreak the VS build by copying some undef code from Utils/LowerInvoke.cpp. llvm-svn: 181938
* X86: Remove redundant test instructionsDavid Majnemer2013-05-151-7/+39
| | | | | | | | Increase the number of instructions LLVM recognizes as setting the ZF flag. This allows us to remove test instructions that redundantly recalculate the flag. llvm-svn: 181937
* Implement PPC counter loops as a late IR-level passHal Finkel2013-05-159-669/+481
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The old PPCCTRLoops pass, like the Hexagon pass version from which it was derived, could only handle some simple loops in canonical form. We cannot directly adapt the new Hexagon hardware loops pass, however, because the Hexagon pass contains a fundamental assumption that non-constant-trip-count loops will contain a guard, and this is not always true (the result being that incorrect negative counts can be generated). With this commit, we replace the pass with a late IR-level pass which makes use of SE to calculate the backedge-taken counts and safely generate the loop-count expressions (including any necessary max() parts). This IR level pass inserts custom intrinsics that are lowered into the desired decrement-and-branch instructions. The most fragile part of this new implementation is that interfering uses of the counter register must be detected on the IR level (and, on PPC, this also includes any indirect branches in addition to function calls). Also, to make all of this work, we need a variant of the mtctr instruction that is marked as having side effects. Without this, machine-code level CSE, DCE, etc. illegally transform the resulting code. Hopefully, this can be improved in the future. This new pass is smaller than the original (and much smaller than the new Hexagon hardware loops pass), and can handle many additional cases correctly. In addition, the preheader-creation code has been copied from LoopSimplify, and after we decide on where it belongs, this code will be refactored so that it can be explicitly shared (making this implementation even smaller). The new test-case files ctrloop-{le,lt,ne}.ll have been adapted from tests for the new Hexagon pass. There are a few classes of loops that this pass does not transform (noted by FIXMEs in the files), but these deficiencies can be addressed within the SE infrastructure (thus helping many other passes as well). llvm-svn: 181927
* Fix legalization of SETCC with promoted integer intrinsicsHal Finkel2013-05-151-2/+13
| | | | | | | | | | | | | | | | | | If the input operands to SETCC are promoted, we need to make sure that we either use the promoted form of both operands (or neither); a mixture is not allowed. This can happen, for example, if a target has a custom promoted i1-returning intrinsic (where i1 is not a legal type). In this case, we need to use the promoted form of both operands. This change only augments the behavior of the existing logic in the case where the input types (which may or may not have already been legalized) disagree, and should not affect existing target code because this case would otherwise cause an assert in the SETCC operand promotion code. This will be covered by (essentially all of the) tests for the new PPCCTRLoops infrastructure. llvm-svn: 181926
* Fix miscompile due to StackColoring incorrectly merging stack slots (PR15707)Derek Schuff2013-05-151-11/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | IR optimisation passes can result in a basic block that contains: llvm.lifetime.start(%buf) ... llvm.lifetime.end(%buf) ... llvm.lifetime.start(%buf) Before this change, calculateLiveIntervals() was ignoring the second lifetime.start() and was regarding %buf as being dead from the lifetime.end() through to the end of the basic block. This can cause StackColoring to incorrectly merge %buf with another stack slot. Fix by removing the incorrect Starts[pos].isValid() and Finishes[pos].isValid() checks. Just doing: Starts[pos] = Indexes->getMBBStartIdx(MBB); Finishes[pos] = Indexes->getMBBEndIdx(MBB); unconditionally would be enough to fix the bug, but it causes some test failures due to stack slots not being merged when they were before. So, in order to keep the existing tests passing, treat LiveIn and LiveOut separately rather than approximating the live ranges by merging LiveIn and LiveOut. This fixes PR15707. Patch by Mark Seaborn. llvm-svn: 181922
* Cleanup relocation sorting for ELF.Rafael Espindola2013-05-152-46/+16
| | | | | | | | | | We want the order to be deterministic on all platforms. NAKAMURA Takumi fixed that in r181864. This patch is just two small cleanups: * Move the function to the cpp file. It is only passed to array_pod_sort. * Remove the ppc implementation which is now redundant llvm-svn: 181910
* PPCISelLowering.h: Escape \@ in comments. [-Wdocumentation]NAKAMURA Takumi2013-05-151-14/+14
| | | | llvm-svn: 181907
* Whitespace.NAKAMURA Takumi2013-05-151-2/+2
| | | | llvm-svn: 181906
* [objc-arc] Fixed a spelling error and made the statistic descriptions be ↵Michael Gottesman2013-05-151-5/+5
| | | | | | consistent about their usage of periods. llvm-svn: 181901
* Support unaligned load/store on more ARM targetsDerek Schuff2013-05-151-4/+17
| | | | | | | | | | | | | | | | | This patch matches GCC behavior: the code used to only allow unaligned load/store on ARM for v6+ Darwin, it will now allow unaligned load/store for v6+ Darwin as well as for v7+ on other targets. The distinction is made because v6 doesn't guarantee support (but LLVM assumes that Apple controls hardware+kernel and therefore have conformant v6 CPUs), whereas v7 does provide this guarantee (and Linux behaves sanely). Overall this should slightly improve performance in most cases because of reduced I$ pressure. Patch by JF Bastien llvm-svn: 181897
* Remove MCELFObjectTargetWriter::adjustFixupOffset hackUlrich Weigand2013-05-152-7/+0
| | | | | | | | Now that PowerPC no longer uses adjustFixupOffset, and no other back-end (ever?) did, we can remove the infrastructure itself (incidentally addressing a FIXME to that effect). llvm-svn: 181895
* [PowerPC] Remove need for adjustFixupOffst hackUlrich Weigand2013-05-153-24/+10
| | | | | | | | | | | | | | | | Now that applyFixup understands differently-sized fixups, we can define fixup_ppc_lo16/fixup_ppc_lo16_ds/fixup_ppc_ha16 to properly be 2-byte fixups, applied at an offset of 2 relative to the start of the instruction text. This has the benefit that if we actually need to generate a real relocation record, its address will come out correctly automatically, without having to fiddle with the offset in adjustFixupOffset. Tested on both 64-bit and 32-bit PowerPC, using external and integrated assembler. llvm-svn: 181894
* [SystemZ] Make use of SUBTRACT HALFWORDRichard Sandiford2013-05-151-0/+1
| | | | | | Thanks to Ulrich Weigand for noticing that this instruction was missing. llvm-svn: 181893
* [PowerPC] Correctly handle fixups of other than 4 byte sizeUlrich Weigand2013-05-151-3/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | The PPCAsmBackend::applyFixup routine handles the case where a fixup can be resolved within the same object file. However, this routine is currently hard-coded to assume the size of any fixup is always exactly 4 bytes. This is sort-of correct for fixups on instruction text; even though it only works because several of what really would be 2-byte fixups are presented as 4-byte fixups instead (requiring another hack in PPCELFObjectWriter::adjustFixupOffset to clean it up). However, this assumption breaks down completely for fixups on data, which legitimately can be of any size (1, 2, 4, or 8). This patch makes applyFixup aware of fixups of varying sizes, introducing a new helper routine getFixupKindNumBytes (along the lines of what the ARM back end does). Note that in order to handle fixups of size 8, we also need to fix the return type of adjustFixupValue to uint64_t to avoid truncation. Tested on both 64-bit and 32-bit PowerPC, using external and integrated assembler. llvm-svn: 181891
* [SystemZ] Add more future work items to the READMERichard Sandiford2013-05-151-7/+91
| | | | | | Based on an analysis by Ulrich Weigand. llvm-svn: 181882
* Fix build on WindowsTimur Iskhodzhanov2013-05-151-0/+1
| | | | llvm-svn: 181873
* Use only explicit bool conversion operatorsDavid Blaikie2013-05-154-4/+4
| | | | | | | | | | | | | | | | | | | | | | | BitVector/SmallBitVector::reference::operator bool remain implicit since they model more exactly a bool, rather than something else that can be boolean tested. The most common (non-buggy) case are where such objects are used as return expressions in bool-returning functions or as boolean function arguments. In those cases I've used (& added if necessary) a named function to provide the equivalent (or sometimes negative, depending on convenient wording) test. One behavior change (YAMLParser) was made, though no test case is included as I'm not sure how to reach that code path. Essentially any comparison of llvm::yaml::document_iterators would be invalid if neither iterator was at the end. This helped uncover a couple of bugs in Clang - test cases provided for those in a separate commit along with similar changes to `operator bool` instances in Clang. llvm-svn: 181868
* LoopVectorize: Fix commentsArnold Schwaighofer2013-05-151-4/+4
| | | | | | No functionality change. llvm-svn: 181862
* LoopVectorize: Hoist conditional loads if possibleArnold Schwaighofer2013-05-151-3/+102
| | | | | | | | | | | | InstCombine can be uncooperative to vectorization and sink loads into conditional blocks. This prevents vectorization. Undo this optimization if there are unconditional memory accesses to the same addresses in the loop. radar://13815763 llvm-svn: 181860
* Speed up Value::isUsedInBasicBlock() for long use lists.Jakob Stoklund Olesen2013-05-141-14/+13
| | | | | | | | | | | | | | | | This is expanding Ben's original heuristic for short basic blocks to also work for longer basic blocks and huge use lists. Scan the basic block and the use list in parallel, terminating the search when the shorter list ends. In almost all cases, either the basic block or the use list is short, and the function returns quickly. In one crazy test case with very long use chains, CodeGenPrepare runs 400x faster. When compiling ARMDisassembler.cpp it is 5x faster. <rdar://problem/13840497> llvm-svn: 181851
* Fix two typoSylvestre Ledru2013-05-142-2/+2
| | | | llvm-svn: 181848
* Object: Fix Mach-O relocation printing.Ahmed Bougacha2013-05-141-2/+3
| | | | | | | | | There were two problems that made llvm-objdump -r crash: - for non-scattered relocations, the symbol/section index is actually in the (aptly named) symbolnum field. - sections are 1-indexed. llvm-svn: 181843
* ARM ISel: Don't create illegal types during LowerMULArnold Schwaighofer2013-05-141-25/+32
| | | | | | | | | | | | | | | | | The transformation happening here is that we want to turn a "mul(ext(X), ext(X))" into a "vmull(X, X)", stripping off the extension. We have to make sure that X still has a valid vector type - possibly recreate an extension to a smaller type. In case of a extload of a memory type smaller than 64 bit we used create a ext(load()). The problem with doing this - instead of recreating an extload - is that an illegal type is exposed. This patch fixes this by creating extloads instead of ext(load()) sequences. Fixes PR15970. radar://13871383 llvm-svn: 181842
* GlobalOpt: fix an issue where CXAAtExitFn points to a deleted function.Manman Ren2013-05-141-3/+3
| | | | | | | | | | | CXAAtExitFn was set outside a loop and before optimizations where functions can be deleted. This patch will set CXAAtExitFn inside the loop and after optimizations. Seg fault when running LTO because of accesses to a deleted function. rdar://problem/13838828 llvm-svn: 181838
* Make getCompileUnit non-const and return the current DIE if itEric Christopher2013-05-142-3/+3
| | | | | | | happens to be a compile unit. Noticed on inspection and tested via calling on a newly created compile unit. No functional change. llvm-svn: 181835
* Implement the PowerPC system call (sc) instruction.Bill Schmidt2013-05-144-0/+28
| | | | | | Instruction added at request of Roman Divacky. Tested via asm-parser. llvm-svn: 181821
* SectionMemoryManager shouldn't be a JITMemoryManager. Previously, the Filip Pizlo2013-05-143-9/+20
| | | | | | | | | | | | | | | | | EngineBuilder interface required a JITMemoryManager even if it was being used to construct an MCJIT. But the MCJIT actually wants a RTDyldMemoryManager. Consequently, the SectionMemoryManager, which is meant for MCJIT, derived from the JITMemoryManager and then stubbed out a bunch of JITMemoryManager methods that weren't relevant to the MCJIT. This patch fixes the situation: it teaches the EngineBuilder that RTDyldMemoryManager is a supertype of JITMemoryManager, and that it's appropriate to pass a RTDyldMemoryManager instead of a JITMemoryManager if we're using the MCJIT. This allows us to remove the stub methods from SectionMemoryManager, and make SectionMemoryManager a direct subtype of RTDyldMemoryManager. llvm-svn: 181820
* Hexagon: Pass to replace tranfer/copy instructions into combine instructionJyotsna Verma2013-05-145-0/+686
| | | | | | where possible. llvm-svn: 181817
* Reapply "Subtract isn't commutative, fix this for MMX psub." withEric Christopher2013-05-141-7/+7
| | | | | | | a somewhat randomly chosen cpu that will minimize cpu specific differences on bots. llvm-svn: 181814
* Temporarily revert "Subtract isn't commutative, fix this for MMX psub."Eric Christopher2013-05-141-7/+7
| | | | | | It's causing failures on the atom bot. llvm-svn: 181812
* Fix __clear_cache declaration.Rafael Espindola2013-05-141-1/+1
| | | | | | This fixes the build with gcc in gnu++98 and gnu++11 mode. llvm-svn: 181811
* Subtract isn't commutative, fix this for MMX psub.Eric Christopher2013-05-141-7/+7
| | | | | | Patch by Andrea DiBiagio. llvm-svn: 181809
* Recognize sparc64 as an alias for sparcv9 triples.Jakob Stoklund Olesen2013-05-141-1/+1
| | | | | | Patch by Brad Smith! llvm-svn: 181808
* Hexagon: Add patterns to generate 'combine' instructions.Jyotsna Verma2013-05-141-0/+87
| | | | llvm-svn: 181805
* Hexagon: ArePredicatesComplement should not restrict itself to TFRs.Jyotsna Verma2013-05-141-5/+31
| | | | llvm-svn: 181803
* Add bitcast to store of personality function.Kai Nacke2013-05-141-1/+3
| | | | | | | | | | The personality function is user defined and may have an arbitrary result type. The code assumes always i8*. This results in an assertion failure if a different type is used. A bitcast to i8* is added to prevent this failure. Reviewed by: Renato Golin, Bob Wilson llvm-svn: 181802
* PPC32: Fix stack collision between FP and CR save areas.Bill Schmidt2013-05-141-0/+1
| | | | | | | | | | | | | | | | | The changes to CR spill handling missed a case for 32-bit PowerPC. The code in PPCFrameLowering::processFunctionBeforeFrameFinalized() checks whether CR spill has occurred using a flag in the function info. This flag is only set by storeRegToStackSlot and loadRegFromStackSlot. spillCalleeSavedRegisters does not call storeRegToStackSlot, but instead produces MI directly. Thus we don't see the CR is spilled when assigning frame offsets, and the CR spill ends up colliding with some other location (generally the FP slot). This patch sets the flag in spillCalleeSavedRegisters for PPC32 so that the CR spill is properly detected and gets its own slot in the stack frame. llvm-svn: 181800
* Hexagon: Remove dead-code after unconditional return from addPreSched2.Jyotsna Verma2013-05-141-3/+0
| | | | llvm-svn: 181797
* R600/SI: Add processor type for Hainan asicTom Stellard2013-05-142-1/+3
| | | | | | | | | | Patch by: Alex Deucher Reviewed-by: Tom Stellard <thomas.stellard@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> NOTE: This is a candidate for the 3.3 branch. llvm-svn: 181792
* Declare __clear_cache.Rafael Espindola2013-05-141-0/+1
| | | | | | | | GCC declares __clear_cache in the gnu modes (-std=gnu++98, -std=gnu++11), but not in the strict modes (-std=c++98, -std=c++11). This patch declares it and therefore fixes the build when using one of the strict modes. llvm-svn: 181785
* [SystemZ] Add disassembler supportRichard Sandiford2013-05-1411-6/+399
| | | | llvm-svn: 181777
* [SystemZ] Rework handling of constant PC-relative operandsRichard Sandiford2013-05-143-20/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GNU assembler treats things like: brasl %r14, 100 in the same way as: brasl %r14, .+100 rather than as a branch to absolute address 100. We implemented this in LLVM by creating an immediate operand rather than the usual expr operand, and by handling immediate operands specially in the code emitter. This was undesirable for (at least) three reasons: - the specialness of immediate operands was exposed to the backend MC code, rather than being limited to the assembler parser. - in disassembly, an immediate operand really is an absolute address. (Note that this means reassembling printed disassembly can't recreate the original code.) - it would interfere with any assembly manipulation that we might try in future. E.g. operations like branch shortening can change the relative position of instructions, but any code that updates sym+offset addresses wouldn't update an immediate "100" operand in the same way as an explicit ".+100" operand. This patch changes the implementation so that the assembler creates a "." label for immediate PC-relative operands, so that the operand to the MCInst is always the absolute address. The patch also adds some error checking of the offset. llvm-svn: 181773
OpenPOWER on IntegriCloud