summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/PowerPC
Commit message (Collapse)AuthorAgeFilesLines
* Remove the MachineMove class.Rafael Espindola2013-05-132-4/+6
| | | | | | | | | | | | It was just a less powerful and more confusing version of MCCFIInstruction. A side effect is that, since MCCFIInstruction uses dwarf register numbers, calls to getDwarfRegNum are pushed out, which should allow further simplifications. I left the MachineModuleInfo::addFrameMove interface unchanged since this patch was already fairly big. llvm-svn: 181680
* Change getFrameMoves to return a const reference.Rafael Espindola2013-05-111-9/+7
| | | | | | | To add a frame now there is a dedicated addFrameMove which also takes care of constructing the move itself. llvm-svn: 181657
* Remove unused argument.Rafael Espindola2013-05-101-1/+1
| | | | llvm-svn: 181618
* Remove unused isLegalAddressImmediate() method.Roman Divacky2013-05-082-21/+0
| | | | llvm-svn: 181452
* [PowerPC] Fix regression in generating @ha/@l relocsUlrich Weigand2013-05-081-1/+10
| | | | | | | | | | | | | | | | The patch I committed as revision 167864 introduced a regression that causes LLVM to no longer generate appropriate relocs for @ha/@l symbol references (but fail an assertion instead). This is fixed here by re-enabling support for the VK_PPC_GAS_HA16/ VK_PPC_GAS_LO16 variant kinds (and their Darwin variants) in PPCELFObjectWriter.cpp. Tested by running projects/test-suite in -m32 mode with the integrated assembler forced on. A standalone test case will be committed shortly as well. llvm-svn: 181450
* Fix handling of anonymous aggregate parameters for powerpc*-apple-darwin8.Bill Schmidt2013-05-081-4/+4
| | | | | | | | This fixes bug 15821 similarly to the powerpc64-linux fix for bug 14779. Patch by David Fang. llvm-svn: 181449
* PPCInstrInfo::optimizeCompareInstr should not optimize FP comparesHal Finkel2013-05-081-18/+11
| | | | | | | | The floating-point record forms on PPC don't set the condition register bits based on a comparison with zero (like the integer record forms do), but rather based on the exception status bits. llvm-svn: 181423
* Cleanup PPCInstrInfo::optimizeCompareInstrHal Finkel2013-05-071-14/+10
| | | | | | | Implement suggestions by Bill Schmidt in post-commit review. No functionality change intended. llvm-svn: 181338
* [PowerPC] Fix memory corruption in AsmParserUlrich Weigand2013-05-061-7/+7
| | | | | | | | As pointed out by Evgeniy Stepanov, assigning a std::string temporary to a StringRef is not a good idea. Rework MatchRegisterName to avoid using the .lower routine. llvm-svn: 181192
* [PowerPC] Avoid using '$' in generated assembler codeUlrich Weigand2013-05-031-2/+2
| | | | | | | | | | | | PowerPC assemblers are supposed to support a stand-alone '$' symbol as an alternative of '.' to refer to the current PC. This does not work in the LLVM assembler parser yet. To avoid bootstrap failures when using the LLVM assembler as system assembler, this patch modifies the assembler source code generated by LLVM to avoid using '$' (and simply use '.' instead). llvm-svn: 181054
* [PowerPC] Add some Book II instructions to AsmParserUlrich Weigand2013-05-032-0/+17
| | | | | | | | | | | | | This patch adds a couple of Book II instructions (isync, icbi) to the PowerPC assembler parser. These are needed when bootstrapping clang with the integrated assembler forced on, because they are used in inline asm statements in the code base. The test case adds the full list of Book II storage control instructions, including associated extended mnemonics. Again, those that are not yet supported as marked as FIXME. llvm-svn: 181052
* [PowerPC] Support extended mnemonics in AsmParserUlrich Weigand2013-05-032-0/+142
| | | | | | | | | | | | This patch adds infrastructure to support extended mnemonics in the PowerPC assembler parser. It adds support specifically for those extended mnemonics that LLVM will itself generate. The test case lists *all* extended mnemonics according to the PowerPC ISA v2.06 Book I, but marks those not yet supported as FIXME. llvm-svn: 181051
* [PowerPC] Add assembler parserUlrich Weigand2013-05-0310-16/+853
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds assembler parser support to the PowerPC back end. The parser will run for any powerpc-*-* and powerpc64-*-* triples, but was tested only on 64-bit Linux. The supported syntax is intended to be compatible with the GNU assembler. The parser does not yet support all PowerPC instructions, but it does support anything that is generated by LLVM itself. There is no support for testing restricted instruction sets yet, i.e. the parser will always accept any instructions it knows, no matter what feature flags are given. Instruction operands will be checked for validity and errors generated. (Error handling in general could still be improved.) The patch adds a number of test cases to verify instruction and operand encodings. The tests currently cover all instructions from the following PowerPC ISA v2.06 Book I facilities: Branch, Fixed-point, Floating-Point, and Vector. Note that a number of these instructions are not yet supported by the back end; they are marked with FIXME. A number of follow-on check-ins will add extra features. When they are all included, LLVM passes all tests (including bootstrap) when using clang -cc1as as the system assembler. llvm-svn: 181050
* Make all darwin ppc stubs local.Rafael Espindola2013-04-271-1/+9
| | | | | | | This fixes pr15763. Patch by David Fang. llvm-svn: 180657
* PowerPC: Use RegisterOperand instead of RegisterClass operandsUlrich Weigand2013-04-263-432/+452
| | | | | | | | | | | | | | | | | In the default PowerPC assembler syntax, registers are specified simply by number, so they cannot be distinguished from immediate values (without looking at the opcode). This means that the default operand matching logic for the asm parser does not work, and we need to specify custom matchers. Since those can only be specified with RegisterOperand classes and not directly on the RegisterClass, all instructions patterns used by the asm parser need to use a RegisterOperand (instead of a RegisterClass) for all their register operands. This patch adds one RegisterOperand for each RegisterClass, using the same name as the class, just in lower case, and updates all instruction patterns to use RegisterOperand instead of RegisterClass operands. llvm-svn: 180611
* PowerPC: Fix encoding of vsubcuw and vsum4sbs instructionsUlrich Weigand2013-04-261-2/+2
| | | | | | | | | When testing the asm parser, I noticed wrong encodings for the above instructions (wrong sub-opcodes). Tests will be added together with the asm parser. llvm-svn: 180608
* PowerPC: Fix encoding of stfsu and stfdu instructionsUlrich Weigand2013-04-261-2/+2
| | | | | | | | | | | When testing the asm parser, I noticed wrong encodings for the above instructions (wrong sub-opcodes). Note that apparently the compiler currently never generates pre-inc instructions for floating point types for some reason ... Tests will be added together with the asm parser. llvm-svn: 180607
* PowerPC: Fix encoding of rldimi and rldcl instructionsUlrich Weigand2013-04-263-3/+36
| | | | | | | | | | When testing the asm parser, I noticed wrong encodings for the above instructions (wrong operand name in rldimi, wrong form and sub-opcode for rldcl). Tests will be added together with the asm parser. llvm-svn: 180606
* PowerPC: Support PC-relative fixup_ppc_brcond14.Ulrich Weigand2013-04-261-0/+3
| | | | | | | | When testing the asm parser, I ran into an error when using a conditional branch to an external symbol (this doesn't occur in compiler-generated code) due to missing support in PPCELFObjectWriter::getRelocTypeInner. llvm-svn: 180605
* Change commentary for PowerPC Boolean vector contents.Bill Schmidt2013-04-231-1/+2
| | | | | | No functional change intended. llvm-svn: 180131
* DAGCombine should not aggressively fold SEXT(VSETCC(...)) into a wider ↵Owen Anderson2013-04-231-1/+1
| | | | | | | | | VSETCC without first checking the target's vector boolean contents. This exposed an issue with PowerPC AltiVec where it appears it was setting the wrong vector boolean contents. The included change fixes the PowerPC tests, and was OK'd by Hal. llvm-svn: 180129
* Remove unused MEMBARRIER DAG node; it's been replaced by ATOMIC_FENCE.Tim Northover2013-04-201-8/+0
| | | | llvm-svn: 179939
* Move PPC getSwappedPredicate for reuseHal Finkel2013-04-203-17/+20
| | | | | | | | | | | The getSwappedPredicate function can be used in other places (such as in improvements to the PPCCTRLoops pass). Instead of trapping it as a static function in PPCInstrInfo, move it into PPCPredicates with other predicate-related things. No functionality change intended. llvm-svn: 179926
* ArrayRefize getMachineNode(). No functionality change.Michael Liao2013-04-191-7/+7
| | | | llvm-svn: 179901
* Fix PPC optimizeCompareInstr swapped-sub argument handlingHal Finkel2013-04-191-16/+40
| | | | | | | | | | | | | When matching a compare with a subtract where the arguments of the compare are swapped w.r.t. the arguments of the subtract, we need to negate the predicates (or CR bit indices) of the users. This, however, is not the same as inverting the predicate (negating LT -> GT, but inverting LT -> GE, for example). The ARM backend seems to do this correctly, but when I adapted the code for the PPC backend, I introduced an error in this logic. Comparison optimization is now enabled again by default. llvm-svn: 179899
* Disable PPC comparison optimization by defaultHal Finkel2013-04-181-0/+6
| | | | | | | This seems to cause a stage-2 LLVM compile failure (by crashing TableGen); do I'm disabling this for now. llvm-svn: 179807
* Implement optimizeCompareInstr for PPCHal Finkel2013-04-182-0/+312
| | | | | | | | | | | | | | | Many PPC instructions have a so-called 'record form' which stores to a specific condition register the result of comparing the result of the instruction with zero (always as a signed comparison). For integer operations on PPC64, this is always a 64-bit comparison. This implementation is derived from the implementation in the ARM backend; there are some differences because PPC condition registers are allocatable virtual registers (although the record forms always use a specific one), and we look for a matching subtraction instruction after the compare (but before the first use) in addition to before it. llvm-svn: 179802
* Add support for subsections to the ELF assembler. Fixes PR8717.Peter Collingbourne2013-04-171-2/+2
| | | | | | Differential Revision: http://llvm-reviews.chandlerc.com/D598 llvm-svn: 179725
* PowerPC: Mark some more patterns as isCodeGenOnly.Ulrich Weigand2013-04-172-0/+6
| | | | | | | | | | A couple of recently introduced conditional branch patterns also need to be marked as isCodeGenOnly since they cannot be handled by the asm parser. No change in generated code. llvm-svn: 179690
* Mark all PPC comparison instructions as not having side effectsHal Finkel2013-04-152-20/+28
| | | | | | | | | | Now that the CR spilling issues have been resolved, we can remove the unmodeled-side-effect attributes from the comparison instructions (and also mark them as isCompare). By allowing these, by default, to have unmodeled side effects, we were hiding problems with CR spilling; but everything seems much happier now. llvm-svn: 179502
* Fix PPC64 CR spill location for callee-saved registersHal Finkel2013-04-152-35/+50
| | | | | | | | | | | | | | | | This fixes an ABI bug for non-Darwin PPC64. For the callee-saved condition registers, the spill location is specified relative to the stack pointer (SP + 8). However, this is not relative to the SP after the new stack frame is established, but instead relative to the caller's stack pointer (it is stored into the linkage area of the parent's stack frame). So, like with the link register, we don't directly spill the CRs with other callee-saved registers, but just mark them to be spilled during prologue generation. In practice, this reverts r179457 for PPC64 (but leaves it in place for PPC32). llvm-svn: 179500
* Mark all PPC CR registers to be spilled as live-in and tag MFCR appropriatelyHal Finkel2013-04-133-15/+16
| | | | | | | | | | | | Leaving MFCR has having unmodeled side effects is not enough to prevent unwanted instruction reordering post-RA. We could probably apply a stronger barrier attribute, but there is a better way: Add all (not just the first) CR to be spilled as live-in to the entry block, and add all CRs to the MFCR instruction as implicitly killed. Unfortunately, I don't have a small test case. llvm-svn: 179465
* Spill and restore PPC CR registers using the FP when we have oneHal Finkel2013-04-131-6/+14
| | | | | | | | | | For functions that need to spill CRs, and have dynamic stack allocations, the value of the SP during the restore is not what it was during the save, and so we need to use the FP in these cases (as for all of the other spills and restores, but the CR restore has a special code path because its reserved slot, like the link register, is specified directly relative to the adjusted SP). llvm-svn: 179457
* PPC: Remove (broken) nested implicit definition listsHal Finkel2013-04-122-94/+153
| | | | | | | | | | TableGen will not combine nested list 'let' bindings into a single list, and instead uses only the inner scope. As a result, several instruction definitions were missing implicit register defs that were in outer scopes. This de-nests these scopes and makes all instructions have only one let binding which sets implicit register definitions. llvm-svn: 179392
* Add a comment about the PPC Interpretation64Bit bitHal Finkel2013-04-121-0/+5
| | | | llvm-svn: 179391
* Add PPC instruction record forms and associated query functionsHal Finkel2013-04-125-416/+670
| | | | | | | | | | | | | | | | | | This is prep. work for the implementation of optimizeCompare. Many PPC instructions have 'record' forms (in almost all cases, this means that the RC bit is set) that cause the result of the instruction to be compared with zero, and the result of that comparison saved in a predefined condition register. In order to add the record forms of the instructions without too much copy-and-paste, the relevant functions have been refactored into multiclasses which define both the record and normal forms. Also, two TableGen-generated mapping functions have been added which allow querying the instruction code for the record form given the normal form (and vice versa). No functionality change intended. llvm-svn: 179356
* Make PPCInstrInfo::isPredicated always return falseHal Finkel2013-04-111-16/+8
| | | | | | | Because of how predication in implemented on PPC (only for branches), I think that this is the right thing to do. No functionality change intended. llvm-svn: 179252
* PPC: Don't predicate a diamond with two counter decrementsHal Finkel2013-04-102-3/+24
| | | | | | | | | | I've not seen this happen in practice, and probably can't until we start allowing decrement-counter-based conditional branches to be double predicated, but just in case, don't allow predication of a diamond in which both sides have ctr-defining branches. Even though the branching behavior of these can be predicated, the counter-decrementing behavior cannot be. llvm-svn: 179199
* Cleanup PPCInstrInfo::DefinesPredicateHal Finkel2013-04-101-5/+10
| | | | | | Implement suggestions made by Bill Schmidt in post-commit review. Thanks! llvm-svn: 179162
* PPC: Prep for if conversion of bctr[l]Hal Finkel2013-04-103-2/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | This adds in-principle support for if-converting the bctr[l] instructions. These instructions are used for indirect branching. It seems, however, that the current if converter will never actually predicate these. To do so, it would need the ability to hoist a few setup insts. out of the conditionally-executed block. For example, code like this: void foo(int a, int (*bar)()) { if (a != 0) bar(); } becomes: ... beq 0, .LBB0_2 std 2, 40(1) mr 12, 4 ld 3, 0(4) ld 11, 16(4) ld 2, 8(4) mtctr 3 bctrl ld 2, 40(1) .LBB0_2: ... and it would be safe to do all of this unconditionally with a predicated beqctrl instruction. llvm-svn: 179156
* Allow PPC B and BLR to be if-converted into some predicated formsHal Finkel2013-04-095-0/+208
| | | | | | | | | | | | | | This enables us to form predicated branches (which are the same conditional branches we had before) and also a larger set of predicated returns (including instructions like bdnzlr which is a conditional return and loop-counter decrement all in one). At the moment, if conversion does not capture all possible opportunities. A simple example is provided in early-ret2.ll, where if conversion forms one predicated return, and then the PPCEarlyReturn pass picks up the other one. So, at least for now, we'll keep both mechanisms. llvm-svn: 179134
* Cleanup PPCEarlyReturnHal Finkel2013-04-091-28/+31
| | | | | | | | | | Some general cleanup and only scan the end of a BB for branches (once we're done with the terminators and debug values, then there should not be any other branches). These address post-commit review suggestions by Bill Schmidt. No functionality change intended. llvm-svn: 179112
* Use virtual base registers on PPCHal Finkel2013-04-092-15/+164
| | | | | | | | | | | | On PowerPC, non-vector loads and stores have r+i forms; however, in functions with large stack frames these were not being used to access slots far from the stack pointer because such slots were out of range for the signed 16-bit immediate offset field. This increases register pressure because we need a separate register for each offset (when the r+r form is used). By enabling virtual base registers, we can deal with large stack frames without unduly increasing register pressure. llvm-svn: 179105
* Generate PPC early conditional returnsHal Finkel2013-04-086-24/+160
| | | | | | | | | | | | | PowerPC has a conditional branch to the link register (return) instruction: BCLR. This should be used any time when we'd otherwise have a conditional branch to a return. This adds a small pass, PPCEarlyReturn, which runs just prior to the branch selection pass (and, importantly, after block placement) to generate these conditional returns when possible. It will also eliminate unconditional branches to returns (these happen rarely; most of the time these have already been tail duplicated by the time PPCEarlyReturn is invoked). This is a nice optimization for small functions that do not maintain a stack frame. llvm-svn: 179026
* Cleanup and improve PPC fsel generationHal Finkel2013-04-071-7/+33
| | | | | | | | | | | | | First, we should not cheat: fsel-based lowering of select_cc is a finite-math-only optimization (the ISA manual, section F.3 of v2.06, makes this clear, as does a note in our own README). This also adds fsel-based lowering of EQ and NE condition codes. As it turned out, fsel generation was covered by a grand total of zero regression test cases. I've added some test cases to cover the existing behavior (which is now finite-math only), as well as the new EQ cases. llvm-svn: 179000
* PPC rotate instructions don't have unmodeled side effctsHal Finkel2013-04-072-3/+6
| | | | llvm-svn: 178982
* Most PPC M[TF]CR instructions do not have side effectsHal Finkel2013-04-072-5/+19
| | | | llvm-svn: 178978
* PPC pre-increment load instructions do not have side effectsHal Finkel2013-04-071-2/+3
| | | | | | A few were missed in r178972. llvm-svn: 178973
* PPC pre-increment load instructions do not have side effectsHal Finkel2013-04-072-3/+3
| | | | llvm-svn: 178972
* PPC MCRF instruction does not have side effectsHal Finkel2013-04-071-0/+1
| | | | llvm-svn: 178971
OpenPOWER on IntegriCloud