summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/PowerPC/PPCISelLowering.cpp
Commit message (Collapse)AuthorAgeFilesLines
* The getRegForInlineAsmConstraint function should only accept MVT value types.Chad Rosier2013-06-221-1/+1
| | | | llvm-svn: 184642
* [PowerPC] Rename some more VK_PPC_ enumsUlrich Weigand2013-06-211-4/+4
| | | | | | | | | | | | | This renames more VK_PPC_ enums, to make them more closely reflect the @modifier string they represent. This also prepares for adding a bunch of new VK_PPC_ enums in upcoming patches. For consistency, some MO_ flags related to VK_PPC_ enums are likewise renamed. No change in behaviour. llvm-svn: 184547
* [PowerPC] Expose some calling convention functions in PPCISelLowering.h.Bill Schmidt2013-06-121-29/+14
| | | | | | | | | | | | | | This is a preparatory patch for fast-isel support. The instruction selector will need to access some functions in PPCGenCallingConv.inc, which in turn requires several helper functions to be defined. These are currently defined near the only use of PCCGenCallingConv.inc, inside PPCISelLowering.cpp. This patch moves the declaration of the functions into the associated header file to provide the needed visibility. No functional change intended. llvm-svn: 183844
* Don't cache the instruction and register info from the TargetMachine, becauseBill Wendling2013-06-071-5/+7
| | | | | | | | the internals of TargetMachine could change. No functionality change intended. llvm-svn: 183494
* Order CALLSEQ_START and CALLSEQ_END nodes.Andrew Trick2013-05-291-7/+12
| | | | | | | | | | | | Fixes PR16146: gdb.base__call-ar-st.exp fails after pre-RA-sched=source fixes. Patch by Xiaoyi Guo! This also fixes an unsupported dbg.value test case. Codegen was previously incorrect but the test was passing by luck. llvm-svn: 182885
* PPC: Add a isConsecutiveLS utility functionHal Finkel2013-05-271-2/+42
| | | | | | | | | | | | | isConsecutiveLS is a slightly more general form of SelectionDAG::isConsecutiveLoad. Aside from also handling stores, it also does not assume equality of the chain operands is necessary. In the case of the PPC backend, this chain condition is checked in a more general way by the surrounding code. Mostly, this part of the refactoring in preparation for supporting optimized unaligned stores. llvm-svn: 182723
* Prefer to duplicate PPC Altivec loads when expanding unaligned loadsHal Finkel2013-05-261-3/+79
| | | | | | | | | | | | | | | | | | | When expanding unaligned Altivec loads, we use the decremented offset trick to prevent page faults. Unfortunately, if we have a sequence of consecutive unaligned loads, this leads to suboptimal code generation because the 'extra' load from the first unaligned load can be combined with the base load from the second (but only if the decremented offset trick is not used for the first). Search up and down the chain, through loads and token factors, looking for consecutive loads, and if one is found, don't use the offset reduction trick. These duplicate loads are later combined to yield the desired sequence (in the future, we might want a more-powerful chain search, but that will require some changes to allow the combiner routines to access the AA object). This should complete the initial implementation of the optimized unaligned Altivec load expansion. There is some refactoring that should be done, but that will happen when the unaligned store expansion is added. llvm-svn: 182719
* PPC: Combine duplicate (offset) lvsl Altivec intrinsicsHal Finkel2013-05-251-1/+28
| | | | | | | | | The lvsl permutation control instruction is a function only of the alignment of the pointer operand (relative to the 16-byte natural alignment of Altivec vectors). As a result, multiple lvsl intrinsics where the operands differ by a multiple of 16 can be combined. llvm-svn: 182708
* Track IR ordering of SelectionDAG nodes 2/4.Andrew Trick2013-05-251-62/+61
| | | | | | | Change SelectionDAG::getXXXNode() interfaces as well as call sites of these functions to pass in SDLoc instead of DebugLoc. llvm-svn: 182703
* PPC: Initial support for permutation-based unaligned Altivec loadsHal Finkel2013-05-241-0/+129
| | | | | | | | | | | | | | | | | | Altivec only directly supports aligned loads, but the loads have a strange property: If given an unaligned address, they truncate the address to the next lower aligned address, and load from there. This property, along with an extra load and some special-purpose permutation-control instructions that generate the appropriate permutations from the original unaligned address, allow efficient lowering of aligned loads. This code uses the trick explained in the Apple Velocity Engine optimization overview document to prevent the needed extra load from possibly causing a page fault if the original address happens to be aligned. As noted in the FIXMEs, there are several additional optimizations that can be performed to reduce the cost of these loads even more. These will be implemented in future commits. llvm-svn: 182691
* Add LLVMContext argument to getSetCCResultTypeMatt Arsenault2013-05-181-4/+4
| | | | llvm-svn: 182180
* [PowerPC] Use true offset value in "memrix" machine operandsUlrich Weigand2013-05-161-102/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the second part of the change to always return "true" offset values from getPreIndexedAddressParts, tackling the case of "memrix" type operands. This is about instructions like LD/STD that only have a 14-bit field to encode immediate offsets, which are implicitly extended by two zero bits by the machine, so that in effect we can access 16-bit offsets as long as they are a multiple of 4. The PowerPC back end currently handles such instructions by carrying the 14-bit value (as it will get encoded into the actual machine instructions) in the machine operand fields for such instructions. This means that those values are in fact not the true offset, but rather the offset divided by 4 (and then truncated to an unsigned 14-bit value). Like in the case fixed in r182012, this makes common code operations on such offset values not work as expected. Furthermore, there doesn't really appear to be any strong reason why we should encode machine operands this way. This patch therefore changes the encoding of "memrix" type machine operands to simply contain the "true" offset value as a signed immediate value, while enforcing the rules that it must fit in a 16-bit signed value and must also be a multiple of 4. This change must be made simultaneously in all places that access machine operands of this type. However, just about all those changes make the code simpler; in many cases we can now just share the same code for memri and memrix operands. llvm-svn: 182032
* [PowerPC] Report true displacement value from getPreIndexedAddressPartsUlrich Weigand2013-05-161-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DAGCombiner::CombineToPreIndexedLoadStore calls a target routine to decompose a memory address into a base/offset pair. It expects the offset (if constant) to be the true displacement value in order to perform optional additional optimizations; in particular, to convert other uses of the original pointer into uses of the new base pointer after pre-increment. The PowerPC implementation of getPreIndexedAddressParts, however, simply calls SelectAddressRegImm, which returns a TargetConstant. This value is appropriate for encoding into the instruction, but it is not always usable as true displacement value: - Its type is always MVT::i32, even on 64-bit, where addresses ought to be i64 ... this causes the optimization to simply always fail on 64-bit due to this line in DAGCombiner: // FIXME: In some cases, we can be smarter about this. if (Op1.getValueType() != Offset.getValueType()) { - Its value is truncated to an unsigned 16-bit value if negative. This causes the above opimization to generate wrong code. This patch fixes both problems by simply returning the true displacement value (in its original type). This doesn't affect any other user of the displacement. llvm-svn: 182012
* Implement PPC counter loops as a late IR-level passHal Finkel2013-05-151-0/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Implement the PowerPC system call (sc) instruction.Bill Schmidt2013-05-141-0/+1
| | | | | | Instruction added at request of Roman Divacky. Tested via asm-parser. llvm-svn: 181821
* PPC64: Constant initializers with dynamic relocations go in .data.rel.ro.Bill Schmidt2013-05-131-0/+4
| | | | | | | | | | | | | | | | | | | | | This fixes warning messages observed in the oggenc application test in projects/test-suite. Special handling is needed for the 64-bit PowerPC SVR4 ABI when a constant is initialized with a pointer to a function in a shared library. Because a function address is implemented as the address of a function descriptor, the use of copy relocations can lead to problems with initialization. GNU ld therefore replaces copy relocations with dynamic relocations to be resolved by the dynamic linker. This means the constant cannot reside in the read-only data section, but instead belongs in .data.rel.ro, which is designed for constants containing dynamic relocations. The implementation creates a class PPC64LinuxTargetObjectFile inheriting from TargetLoweringObjectFileELF, which behaves like its parent except to place constants of this sort into .data.rel.ro. The test case is reduced from the oggenc application. llvm-svn: 181723
* Remove unused isLegalAddressImmediate() method.Roman Divacky2013-05-081-12/+0
| | | | llvm-svn: 181452
* 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
* 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
* 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
* Enable early if conversion on PPCHal Finkel2013-04-051-22/+7
| | | | | | | | | | | | | On cores for which we know the misprediction penalty, and we have the isel instruction, we can profitably perform early if conversion. This enables us to replace some small branch sequences with selects and avoid the potential stalls from mispredicting the branches. Enabling this feature required implementing canInsertSelect and insertSelect in PPCInstrInfo; isel code in PPCISelLowering was refactored to use these functions as well. llvm-svn: 178926
* Rename the current PPC BCL definition to BCLalwaysHal Finkel2013-04-041-1/+1
| | | | | | | | | | | | BCL is normally a conditional branch-and-link instruction, but has an unconditional form (which is used in the SjLj code, for example). To make clear that this BCL instruction definition is specifically the special unconditional form (which does not meaningfully take a condition-register input), rename it to BCLalways. No functionality change intended. llvm-svn: 178803
* PPC: Improve code generation for mixed-precision reciprocal sqrtHal Finkel2013-04-041-0/+27
| | | | | | | | The DAGCombine logic that recognized a/sqrt(b) and transformed it into a multiplication by the reciprocal sqrt did not handle cases where the sqrt and the division were separated by an fpext or fptrunc. llvm-svn: 178801
* Cleanup PPC reciprocal-estimate functionalityHal Finkel2013-04-031-58/+45
| | | | | | | Incorporating review feedback from Bill Schmidt on r178617. No functionality change intended. llvm-svn: 178672
* Fix PR15632: No support for ppcf128 floating-point remainder on PowerPC.Bill Schmidt2013-04-031-0/+1
| | | | | | | | For this we need to use a libcall. Previously LLVM didn't implement libcall support for frem, so I've added it in the usual straightforward manner. A test case from the bug report is included. llvm-svn: 178639
* Use PPC reciprocal estimates with Newton iteration in fast-math modeHal Finkel2013-04-031-2/+205
| | | | | | | | | | | | | | | | | | | When unsafe FP math operations are enabled, we can use the fre[s] and frsqrte[s] instructions, which generate reciprocal (sqrt) estimates, together with some Newton iteration, in order to quickly generate floating-point division and sqrt results. All of these instructions are separately optional, and so each has its own feature flag (except for the Altivec instructions, which are covered under the existing Altivec flag). Doing this is not only faster than using the IEEE-compliant fdiv/fsqrt instructions, but allows these computations to be pipelined with other computations in order to hide their overall latency. I've also added a couple of missing fnmsub patterns which turned out to be missing (but are necessary for good code generation of the Newton iterations). Altivec needs a similar fix, but that will probably be more complicated because fneg is expanded for Altivec's v4f32. llvm-svn: 178617
* Fix PR15630: Replace faulty stdcx. with stwcx.Bill Schmidt2013-04-021-1/+1
| | | | | | | | | | When doing a partword atomic operation, a lwarx was being paired with a stdcx. instead of a stwcx. when compiling for a 64-bit target. The target has nothing to do with it in this case; we always need a stwcx. Thanks to Kai Nacke for reporting the problem. llvm-svn: 178559
* Fix typo in PPCISelLoweringHal Finkel2013-04-021-1/+1
| | | | | | Thanks to Bill Schmidt for finding this in review of r178480. llvm-svn: 178521
* Fix a bad assert in PPCTargetLoweringHal Finkel2013-04-011-2/+2
| | | | llvm-svn: 178489
* Add more PPC floating-point conversion instructionsHal Finkel2013-04-011-19/+77
| | | | | | | | | The P7 and A2 have additional floating-point conversion instructions which allow a direct two-instruction sequence (plus load/store) to convert from all combinations (signed/unsigned i32/i64) <--> (float/double) (on previous cores, only some combinations were directly available). llvm-svn: 178480
* Add the PPC popcntw instructionHal Finkel2013-04-011-1/+1
| | | | | | | | | The popcntw instruction is available whenever the popcntd instruction is available, and performs a separate popcnt on the lower and upper 32-bits. Ignoring the high-order count, this can be used for the 32-bit input case (saving on the explicit zero extension otherwise required to use popcntd). llvm-svn: 178470
* Treat PPCISD::STFIWX like the memory opcode that it isHal Finkel2013-04-011-2/+9
| | | | | | | | | | | PPCISD::STFIWX is really a memory opcode, and so it should come after FIRST_TARGET_MEMORY_OPCODE, and we should use DAG.getMemIntrinsicNode to create nodes using it. No functionality change intended (although there could be optimization benefits from preserving the MMO information). llvm-svn: 178468
* Add the PPC lfiwax instructionHal Finkel2013-03-311-10/+33
| | | | | | | | | This instruction is available on modern PPC64 CPUs, and is now used to improve the SINT_TO_FP lowering (by eliminating the need for the separate sign extension instruction and decreasing the amount of needed stack space). llvm-svn: 178446
* Cleanup PPC(64) i32 -> float/double conversionHal Finkel2013-03-311-15/+7
| | | | | | | | | | | | | | | The existing SINT_TO_FP code for i32 -> float/double conversion was disabled because it relied on broken EXTSW_32/STD_32 instruction definitions. The original intent had been to enable these 64-bit instructions to be used on CPUs that support them even in 32-bit mode. Unfortunately, this form of lying to the infrastructure was buggy (as explained in the FIXME comment) and had therefore been disabled. This re-enables this functionality, using regular DAG nodes, but only when compiling in 64-bit mode. The old STD_32/EXTSW_32 definitions (which were dead) are removed. llvm-svn: 178438
* Implement FRINT lowering on PPC using frinHal Finkel2013-03-291-0/+49
| | | | | | | | | | | | | | Like nearbyint, rint can be implemented on PPC using the frin instruction. The complication comes from the fact that rint needs to set the FE_INEXACT flag when the result does not equal the input value (and frin does not do that). As a result, we use a custom inserter which, after the rounding, compares the rounded value with the original, and if they differ, explicitly sets the XX bit in the FPSCR register (which corresponds to FE_INEXACT). Once LLVM has better modeling of the floating-point environment we should be able to (often) eliminate this extra complexity. llvm-svn: 178362
* Remove the old CodePlacementOpt pass.Benjamin Kramer2013-03-291-1/+0
| | | | | | It was superseded by MachineBlockPlacement and disabled by default since LLVM 3.1. llvm-svn: 178349
* Add PPC FP rounding instructions fri[mnpz]Hal Finkel2013-03-291-0/+17
| | | | | | | | | These instructions are available on the P5x (and later) and on the A2. They implement the standard floating-point rounding operations (floor, trunc, etc.). One caveat: frin (round to nearest) does not implement "ties to even", and so is only enabled in fast-math mode. llvm-svn: 178337
* Only enable 64-bit bswap DAG combines for PPC64Hal Finkel2013-03-281-0/+2
| | | | | | | | Compiling in 32-bit mode on a P7 would assert after 64-bit DAG combines were added for bswap with load/store. This is because these combines are really only valid in 64-bit mode, regardless of the CPU (and this was not being checked). llvm-svn: 178286
* Fix bad indentation in r178276Hal Finkel2013-03-281-2/+1
| | | | | | Thanks to Bill Schmidt for pointing this out! llvm-svn: 178280
* Add the PPC64 ldbrx/stdbrx instructionsHal Finkel2013-03-281-3/+9
| | | | | | | | These are 64-bit load/store with byte-swap, and available on the P7 and the A2. Like the similar instructions for 16- and 32-bit words, these are matched in the target DAG-combine phase against load/store-bswap pairs. llvm-svn: 178276
* Add the PPC64 popcntd instructionHal Finkel2013-03-281-2/+8
| | | | | | | PPC ISA 2.06 (P7, A2, etc.) has a popcntd instruction. Add this instruction and tell TTI about it so that popcount-loop recognition will know about it. llvm-svn: 178233
* Fix typo (common to both X86 and PPC)Hal Finkel2013-03-271-1/+1
| | | | | | Thanks to Bill Schmidt for pointing this out during code review! llvm-svn: 178170
* PowerPC: Simplify FADD in round-to-zero mode.Ulrich Weigand2013-03-261-47/+26
| | | | | | | | | | | | | | | | | | | | | | | As part of the the sequence generated to implement long double -> int conversions, we need to perform an FADD in round-to-zero mode. This is problematical since the FPSCR is not at all modeled at the SelectionDAG level, and thus there is a risk of getting floating point instructions generated out of sequence with the instructions to modify FPSCR. The current code handles this by somewhat "special" patterns that in part have dummy operands, and/or duplicate existing instructions, making them awkward to handle in the asm parser. This commit changes this by leaving the "FADD in round-to-zero mode" as an atomic operation on the SelectionDAG level, and only split it up into real instructions at the MI level (via custom inserter). Since at *this* level the FPSCR *is* modeled (via the "RM" hard register), much of the "special" stuff can just go away, and the resulting patterns can be used by the asm parser. No significant change in generated code expected. llvm-svn: 178006
* PowerPC: Use CCBITRC operand for ISEL patterns.Ulrich Weigand2013-03-261-15/+15
| | | | | | | | | | | | This commit changes the ISEL patterns to use a CCBITRC operand instead of a "pred" operand. This matches the actual instruction text more directly, and simplifies use of ISEL with the asm parser. In addition, this change allows some simplification of handling the "pred" operand, as this is now only used by BCC. No change in generated code. llvm-svn: 178003
* Remove ABI-duplicated call instruction patterns.Ulrich Weigand2013-03-221-11/+11
| | | | | | | | | | | | | | | | | | We currently have a duplicated set of call instruction patterns depending on the ABI to be followed (Darwin vs. Linux). This is a bit odd; while the different ABIs will result in different instruction sequences, the actual instructions themselves ought to be independent of the ABI. And in fact it turns out that the only nontrivial difference between the two sets of patterns is that in the PPC64 Linux ABI, the instruction used for indirect calls is marked to take X11 as extra input register (which is indeed used only with that ABI to hold an incoming environment pointer for nested functions). However, this does not need to be hard-coded at the .td pattern level; instead, the C++ code expanding calls can simply add that use, just like it adds uses for argument registers anyway. No change in generated code expected. llvm-svn: 177735
* Fix swapped BasePtr and Offset in pre-inc memory addresses.Ulrich Weigand2013-03-221-1/+21
| | | | | | | | | | | | | | | | | | | | PPCTargetLowering::getPreIndexedAddressParts currently provides the base part of a memory address in the offset result, and the offset part in the base result. That swap is then undone again when an MI instruction is generated (in PPCDAGToDAGISel::Select for loads, and using .md Pat patterns for stores). This patch reverts this double swap, to make common code and back-end be in sync as to which part of the address is base and which is offset. To avoid performance regressions in certain cases, target code now checks whether the choice of base register would be rejected for pre-inc accesses by common code, and attempts to swap base and offset again in such cases. (Overall, this means that now pre-ice accesses are generated *more* frequently than before.) llvm-svn: 177733
* Remove the G8RC_NOX0_and_GPRC_NOR0 PPC register classHal Finkel2013-03-211-5/+8
| | | | | | | | | | | | As Jakob pointed out in his review of r177423, having a shared ZERO register between the 32- and 64-bit register classes causes this odd G8RC_NOX0_and_GPRC_NOR0 class to be created. As recommended, this adds a ZERO8 register which differentiates the 32- and 64-bit zeros. No functionality change intended. llvm-svn: 177683
* Implement builtin_{setjmp/longjmp} on PPCHal Finkel2013-03-211-0/+258
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements SJLJ lowering on PPC, making the Clang functions __builtin_{setjmp/longjmp} functional on PPC platforms. The implementation strategy is similar to that on X86, with the exception that a branch-and-link variant is used to get the right jump address. Credit goes to Bill Schmidt for suggesting the use of the unconditional bcl form (instead of the regular bl instruction) to limit return-address-cache pollution. Benchmarking the speed at -O3 of: static jmp_buf env_sigill; void foo() { __builtin_longjmp(env_sigill,1); } main() { ... for (int i = 0; i < c; ++i) { if (__builtin_setjmp(env_sigill)) { goto done; } else { foo(); } done:; } ... } vs. the same code using the libc setjmp/longjmp functions on a P7 shows that this builtin implementation is ~4x faster with Altivec enabled and ~7.25x faster with Altivec disabled. This comparison is somewhat unfair because the libc version must also save/restore the VSX registers which we don't yet support. llvm-svn: 177666
* Correct PPC FRAMEADDR lowering using a pseudo-registerHal Finkel2013-03-211-7/+10
| | | | | | | | | | | | | | | | The old code used to lower FRAMEADDR tried to replicate the logic in the real frame-lowering code that determines whether or not the frame pointer (r31) will be used. When it seemed as through the frame pointer would not be used, the stack pointer (r1) was used instead. Unfortunately, because the stack size is not yet known, this does not work. Instead, this change introduces new always-reserved pseudo-registers (FP and FP8) that are replaced during prologue insertion with the real frame-pointer register (either r1 or r31). It is important that this intrinsic always return a valid frame address because it is used by Clang to store the frame address as part of code generation for __builtin_setjmp. llvm-svn: 177653
OpenPOWER on IntegriCloud