summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/PowerPC/PPCInstrInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [Power9] Add support for -mcpu=pwr9 in the back endNemanja Ivanovic2016-05-091-0/+4
| | | | | | | | | This patch corresponds to review: http://reviews.llvm.org/D19683 Simply adds the bits for being able to specify -mcpu=pwr9 to the back end. llvm-svn: 268950
* [PowerPC] [SSP] Fix stack guard load for 32-bit.Marcin Koscielnicki2016-04-211-1/+1
| | | | | | | | r266809 incorrectly used LD to load the stack guard, it should be LWZ. Differential Revision: http://reviews.llvm.org/D19358 llvm-svn: 267017
* [PPC, SSP] Support PowerPC Linux stack protection.Tim Shen2016-04-191-0/+16
| | | | llvm-svn: 266809
* [PPC64] Mark CR0 Live if PPCInstrInfo::optimizeCompareInstr Creates a Use of CR0Chuang-Yu Cheng2016-04-121-0/+4
| | | | | | | | | | | | | | Resolve Bug 27046 (https://llvm.org/bugs/show_bug.cgi?id=27046). The PPCInstrInfo::optimizeCompareInstr function could create a new use of CR0, even if CR0 were previously dead. This patch marks CR0 live if a use of CR0 is created. Author: Tom Jablin (tjablin) Reviewers: hfinkel kbarton cycheng http://reviews.llvm.org/D18884 llvm-svn: 266040
* Codegen: [PPC] Word Rotates are Zero Extending.Kyle Butt2016-03-231-1/+8
| | | | | | | Add Word rotates to the list of instructions that are zero extending. This allows them to be used in dot form to compare with zero. llvm-svn: 264183
* CodeGen: TII: Take MachineInstr& in predicate API, NFCDuncan P. N. Exon Smith2016-02-231-64/+61
| | | | | | | | | | | | | Change TargetInstrInfo API to take `MachineInstr&` instead of `MachineInstr*` in the functions related to predicated instructions (I'll try to come back later and get some of the rest). All of these functions require non-null parameters already, so references are more clear. As a bonus, this happens to factor away a host of implicit iterator => pointer conversions. No functionality change intended. llvm-svn: 261605
* Remove uses of builtin comma operator.Richard Trieu2016-02-181-6/+6
| | | | | | Cleanup for upcoming Clang warning -Wcomma. No functionality change intended. llvm-svn: 261270
* Codegen: [PPC] Silence false-positive initialization warning. NFCKyle Butt2016-01-151-2/+2
| | | | | | | | | | Some compilers don't do exhaustive switch checking. For those compilers, add an initialization to prevent un-initialized variable warnings from firing. For compilers with exhaustive switch checking, we still get a guarantee that the switch is exhaustive, and hence the initializations are redundant, and a non-functional change. llvm-svn: 257923
* Codegen: [PPC] Handle weighted comparisons when inserting selects.Kyle Butt2016-01-121-10/+33
| | | | | | | | | | | | | Only non-weighted predicates were handled in PPCInstrInfo::insertSelect. Handle the weighted predicates as well. This latent bug was triggered by r255398, because it added use of the branch-weighted predicates. While here, switch over an enum instead of an int to get the compiler to enforce totality in the future. llvm-svn: 257518
* Replace uint16_t with the MCPhysReg typedef in many places. A lot of ↵Craig Topper2015-12-051-2/+2
| | | | | | physical register arrays already use this typedef. llvm-svn: 254843
* replace MachineCombinerPattern namespace and enum with enum class; NFCISanjay Patel2015-11-051-1/+1
| | | | | | | | Also, remove an enum hack where enum values were used as indexes into an array. We may want to make this a real class to allow pattern-based queries/customization (D13417). llvm-svn: 252196
* Improved the interface of methods commuting operands, improved X86-FMA3 ↵Andrew Kaylor2015-09-281-8/+10
| | | | | | | | | | mem-folding&coalescing. Patch by Slava Klochkov (vyacheslav.n.klochkov@intel.com) Differential Revision: http://reviews.llvm.org/D11370 llvm-svn: 248735
* [Machine Combiner] Refactor machine reassociation code to be target-independent.Chad Rosier2015-09-211-211/+6
| | | | | | | | | | No functional change intended. Patch by Haicheng Wu <haicheng@codeaurora.org>! http://reviews.llvm.org/D12887 PR24522 llvm-svn: 248164
* Pass BranchProbability/BlockMass by value instead of const& as they are ↵Cong Hou2015-09-101-1/+1
| | | | | | small. NFC. llvm-svn: 247357
* [PowerPC] Don't commute trivial rlwimi instructionsHal Finkel2015-09-061-0/+5
| | | | | | | | | | | | | | | To commute a trivial rlwimi instructions (meaning one with a full mask and zero shift), we'd need to ability to form an all-zero mask (instead of an all-one mask) using rlwimi. We can't represent this, however, and we'll miscompile code if we try. The code quality problem that this highlights (that SDAG simplification can lead to us generating an ISD::OR node with a constant zero LHS) will be fixed as a follow-up. Fixes PR24719. llvm-svn: 246937
* [MIR Serialization] static -> static const in ↵Hal Finkel2015-08-301-2/+2
| | | | | | | | | getSerializable*MachineOperandTargetFlags Make the arrays 'static const' instead of just 'static'. Post-commit review comment from Roman Divacky on IRC. NFC. llvm-svn: 246376
* [PowerPC/MIR Serialization] Target flags serialization supportHal Finkel2015-08-301-0/+32
| | | | | | | | | | | | | Add support for MIR serialization of PowerPC-specific operand target flags (based on the generic infrastructure added in r244185 and r245383). I won't even pretend that this is good test coverage, but this includes the regression test associated with r246372. Adding an MIR test for that fix is far superior to adding an IR-level test because particular instruction-scheduling decisions are necessary in order to expose the bug, and using an MIR test we can start the pipeline post-scheduling. llvm-svn: 246373
* PseudoSourceValue: Replace global manager with a manager in a machine function.Alex Lorenz2015-08-111-10/+8
| | | | | | | | | | | | | | | | | | | | | | This commit removes the global manager variable which is responsible for storing and allocating pseudo source values and instead it introduces a new manager class named 'PseudoSourceValueManager'. Machine functions now own an instance of the pseudo source value manager class. This commit also modifies the 'get...' methods in the 'MachinePointerInfo' class to construct pseudo source values using the instance of the pseudo source value manager object from the machine function. This commit updates calls to the 'get...' methods from the 'MachinePointerInfo' class in a lot of different files because those calls now need to pass in a reference to a machine function to those methods. This change will make it easier to serialize pseudo source values as it will enable me to transform the mips specific MipsCallEntry PseudoSourceValue subclass into two target independent subclasses. Reviewers: Akira Hatanaka llvm-svn: 244693
* [PowerPC] Use the MachineCombiner to reassociate fadd/fmulHal Finkel2015-07-151-0/+262
| | | | | | | | | | | | | This is a direct port of the code from the X86 backend (r239486/r240361), which uses the MachineCombiner to reassociate (floating-point) adds/muls to increase ILP, to the PowerPC backend. The rationale is the same. There is a lot of copy-and-paste here between the X86 code and the PowerPC code, and we should extract at least some of this into CodeGen somewhere. However, I don't want to do that until this code is enhanced to handle FMAs as well. After that, we'll be in a better position to extract the common parts. llvm-svn: 242279
* [PowerPC] Fix the PPCInstrInfo::getInstrLatency implementationHal Finkel2015-07-141-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PowerPC uses itineraries to describe processor pipelines (and dispatch-group restrictions for P7/P8 cores). Unfortunately, the target-independent implementation of TII.getInstrLatency calls ItinData->getStageLatency, and that looks for the largest cycle count in the pipeline for any given instruction. This, however, yields the wrong answer for the PPC itineraries, because we don't encode the full pipeline. Because the functional units are fully pipelined, we only model the initial stages (there are no relevant hazards in the later stages to model), and so the technique employed by getStageLatency does not really work. Instead, we should take the maximum output operand latency, and that's what PPCInstrInfo::getInstrLatency now does. This caused some test-case churn, including two unfortunate side effects. First, the new arrangement of copies we get from function parameters now sometimes blocks VSX FMA mutation (a FIXME has been added to the code and the test cases), and we have one significant test-suite regression: SingleSource/Benchmarks/BenchmarkGame/spectral-norm 56.4185% +/- 18.9398% In this benchmark we have a loop with a vectorized FP divide, and it with the new scheduling both divides end up in the same dispatch group (which in this case seems to cause a problem, although why is not exactly clear). The grouping structure is hard to predict from the bottom of the loop, and there may not be much we can do to fix this. Very few other test-suite performance effects were really significant, but almost all weakly favor this change. However, in light of the issues highlighted above, I've left the old behavior available via a command-line flag. llvm-svn: 242188
* [PPC] Replace debug value skipping with getLastNonDebugInstr.Benjamin Kramer2015-06-251-16/+7
| | | | | | No functionality change intended. llvm-svn: 240641
* [CodeGen] ArrayRef'ize cond/pred in various TII APIs. NFC.Ahmed Bougacha2015-06-111-10/+7
| | | | llvm-svn: 239553
* Remove 3 includes from MCInstrDesc.h and explicitly include them where neededPete Cooper2015-05-151-0/+1
| | | | llvm-svn: 237481
* Add VSX Scalar loads and stores to the PPC back endNemanja Ivanovic2015-05-071-1/+12
| | | | | | | | | | | This patch corresponds to review: http://reviews.llvm.org/D9440 It adds a new register class to the PPC back end to contain single precision values in VSX registers. Additionally, it adds scalar loads and stores for VSX registers. llvm-svn: 236755
* Add Hardware Transactional Memory (HTM) SupportKit Barton2015-03-251-0/+53
| | | | | | | | | | | | | | | | | | | | | | | | This patch adds Hardware Transaction Memory (HTM) support supported by ISA 2.07 (POWER8). The intrinsic support is based on GCC one [1], but currently only the 'PowerPC HTM Low Level Built-in Function' are implemented. The HTM instructions follows the RC ones and the transaction initiation result is set on RC0 (with exception of tcheck). Currently approach is to create a register copy from CR0 to GPR and comapring. Although this is suboptimal, since the branch could be taken directly by comparing the CR0 value, it generates code correctly on both test and branch and just return value. A possible future optimization could be elimitate the MFCR instruction to branch directly. The HTM usage requires a recently newer kernel with PPC HTM enabled. Tested on powerpc64 and powerpc64le. This is send along a clang patch to enabled the builtins and option switch. [1] https://gcc.gnu.org/onlinedocs/gcc/PowerPC-Hardware-Transactional-Memory-Built-in-Functions.html Phabricator Review: http://reviews.llvm.org/D8247 llvm-svn: 233204
* Disabling warnings for MSVC build to enable /W4 use.Andrew Kaylor2015-03-241-2/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D8572 llvm-svn: 233133
* Remove the need to cache the subtarget in the PowerPC TargetRegisterInfoEric Christopher2015-03-121-1/+1
| | | | | | | classes. Replace it with a cache to the TargetMachine and use that where applicable at the moment. llvm-svn: 232002
* [PowerPC] Add support for the QPX vector instruction setHal Finkel2015-02-251-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | This adds support for the QPX vector instruction set, which is used by the enhanced A2 cores on the IBM BG/Q supercomputers. QPX vectors are 256 bytes wide, holding 4 double-precision floating-point values. Boolean values, modeled here as <4 x i1> are actually also represented as floating-point values (essentially { -1, 1 } for { false, true }). QPX shares many features with Altivec and VSX, but is distinct from both of them. One major difference is that, instead of adding completely-separate vector registers, QPX vector registers are extensions of the scalar floating-point registers (lane 0 is the corresponding scalar floating-point value). The operations supported on QPX vectors mirrors that supported on the scalar floating-point values (with some additional ones for permutations and logical/comparison operations). I've been maintaining this support out-of-tree, as part of the bgclang project, for several years. This is not the entire bgclang patch set, but is most of the subset that can be cleanly integrated into LLVM proper at this time. Adding this to the LLVM backend is part of my efforts to rebase bgclang to the current LLVM trunk, but is independently useful (especially for codes that use LLVM as a JIT in library form). The assembler/disassembler test coverage is complete. The CodeGen test coverage is not, but I've included some tests, and more will be added as follow-up work. llvm-svn: 230413
* [PowerPC] Support non-direct-sub/superclass VSX copiesHal Finkel2015-02-161-4/+4
| | | | | | | | | | | | | | | | Our register allocation has become better recently, it seems, and is now starting to generate cross-block copies into inflated register classes. These copies are not transformed into subregister insertions/extractions by the PPCVSXCopy class, and so need to be handled directly by PPCInstrInfo::copyPhysReg. The code to do this was *almost* there, but not quite (it was unnecessarily restricting itself to only the direct sub/super-register-class case (not copying between, for example, something in VRRC and the lower-half of VSRC which are super-registers of F8RC). Triggering this behavior manually is difficult; I'm including two bugpoint-reduced test cases from the test suite. llvm-svn: 229457
* [PowerPC] Put PPCEarlyReturn into its own source fileHal Finkel2015-02-011-165/+0
| | | | | | | | | | | PPCInstrInfo.cpp has ended up containing several small MI-level passes, and this is making the file harder to read than necessary. Split out PPCEarlyReturn into its own source file. NFC. Now that PPCInstrInfo.cpp does not also contain pass implementations, I hope that it will be slightly less unwieldy. llvm-svn: 227775
* [PowerPC] Put PPCVSXCopy into its own source fileHal Finkel2015-02-011-139/+0
| | | | | | | | PPCInstrInfo.cpp has ended up containing several small MI-level passes, and this is making the file harder to read than necessary. Split out PPCVSXCopy into its own source file. NFC. llvm-svn: 227771
* [PowerPC] Put PPCVSXFMAMutate into its own source fileHal Finkel2015-02-011-291/+0
| | | | | | | | PPCInstrInfo.cpp has ended up containing several small MI-level passes, and this is making the file harder to read than necessary. Split out PPCVSXFMAMutate into its own source file. NFC. llvm-svn: 227770
* [PowerPC] Remove the PPCVSXCopyCleanup passHal Finkel2015-02-011-76/+0
| | | | | | | | | | | This MI-level pass was necessary when VSX support was first being developed, specifically, before the ABI code had been updated to use VSX registers for arguments (the register assignments did not change, in a physical sense, but the VSX super-registers are now used). Unfortunately, I never went back and removed this pass after that was done. I believe this code is now effectively dead. llvm-svn: 227767
* [PowerPC] Add implicit ops to conditional returns in PPCEarlyReturnHal Finkel2015-02-011-8/+13
| | | | | | | | | | | | | When PPCEarlyReturn, it should really copy implicit ops from the old return instruction to the new one. This currently does not matter much, because we run PPCEarlyReturn very late in the pipeline (there is nothing to do DCE on definitions of those registers). However, for completeness, we should do it anyway. Noticed by inspection (and there should be no functional change); thus, no test case. llvm-svn: 227763
* Use the cached subtargets and remove calls to getSubtarget/getSubtargetImplEric Christopher2015-01-301-23/+17
| | | | | | without a Function argument. llvm-svn: 227622
* Revert "r225811 - Revert "r225808 - [PowerPC] Add StackMap/PatchPoint support""Hal Finkel2015-01-141-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This re-applies r225808, fixed to avoid problems with SDAG dependencies along with the preceding fix to ScheduleDAGSDNodes::RegDefIter::InitNodeNumDefs. These problems caused the original regression tests to assert/segfault on many (but not all) systems. Original commit message: This commit does two things: 1. Refactors PPCFastISel to use more of the common infrastructure for call lowering (this lets us take advantage of this common code for lowering some common intrinsics, stackmap/patchpoint among them). 2. Adds support for stackmap/patchpoint lowering. For the most part, this is very similar to the support in the AArch64 target, with the obvious differences (different registers, NOP instructions, etc.). The test cases are adapted from the AArch64 test cases. One difference of note is that the patchpoint call sequence takes 24 bytes, so you can't use less than that (on AArch64 you can go down to 16). Also, as noted in the docs, we take the patchpoint address to be the actual code address (assuming the call is local in the TOC-sharing sense), which should yield higher performance than generating the full cross-DSO indirect-call sequence and is likely just as useful for JITed code (if not, we'll change it). StackMaps and Patchpoints are still marked as experimental, and so this support is doubly experimental. So go ahead and experiment! llvm-svn: 225909
* Revert "r225808 - [PowerPC] Add StackMap/PatchPoint support"Hal Finkel2015-01-131-6/+0
| | | | | | | Reverting this while I investiage buildbot failures (segfaulting in GetCostForDef at ScheduleDAGRRList.cpp:314). llvm-svn: 225811
* [PowerPC] Add StackMap/PatchPoint supportHal Finkel2015-01-131-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | This commit does two things: 1. Refactors PPCFastISel to use more of the common infrastructure for call lowering (this lets us take advantage of this common code for lowering some common intrinsics, stackmap/patchpoint among them). 2. Adds support for stackmap/patchpoint lowering. For the most part, this is very similar to the support in the AArch64 target, with the obvious differences (different registers, NOP instructions, etc.). The test cases are adapted from the AArch64 test cases. One difference of note is that the patchpoint call sequence takes 24 bytes, so you can't use less than that (on AArch64 you can go down to 16). Also, as noted in the docs, we take the patchpoint address to be the actual code address (assuming the call is local in the TOC-sharing sense), which should yield higher performance than generating the full cross-DSO indirect-call sequence and is likely just as useful for JITed code (if not, we'll change it). StackMaps and Patchpoints are still marked as experimental, and so this support is doubly experimental. So go ahead and experiment! llvm-svn: 225808
* [PowerPC] Split the blr definition into BLR and BLR8Hal Finkel2015-01-131-3/+5
| | | | | | | | | | We really need a separate 64-bit version of this instruction so that it can be marked as clobbering LR8 (instead of just LR). No change in functionality (although the verifier might be slightly happier), however, it is required for stackmap/patchpoint support. Thus, this will be covered by stackmap test cases once those are added. llvm-svn: 225804
* [PowerPC] Add a DAGToDAG peephole to remove unnecessary zero-extsHal Finkel2014-12-121-3/+5
| | | | | | | | | | | | | | | | | | | | On PPC64, we end up with lots of i32 -> i64 zero extensions, not only from all of the usual places, but also from the ABI, which specifies that values passed are zero extended. Almost all 32-bit PPC instructions in PPC64 mode are defined to do *something* to the higher-order bits, and for some instructions, that action clears those bits (thus providing a zero-extended result). This is especially common after rotate-and-mask instructions. Adding an additional instruction to zero-extend the results of these instructions is unnecessary. This PPCISelDAGToDAG peephole optimization examines these zero-extensions, and looks back through their operands to see if all instructions will implicitly zero extend their results. If so, we convert these instructions to their 64-bit variants (which is an internal change only, the actual encoding of these instructions is the same as the original 32-bit ones) and remove the unnecessary zero-extension (changing where the INSERT_SUBREG instructions are to make everything internally consistent). llvm-svn: 224169
* [PowerPC] Avoid VSX FMA mutate when killed product reg = addend regBill Schmidt2014-10-211-0/+6
| | | | | | | | | | | | | | | | | | | | | With VSX enabled, test/CodeGen/PowerPC/recipest.ll exposes a bug in the FMA mutation pass. If we have a situation where a killed product register is the same register as the FMA target, such as: %vreg5<def,tied1> = XSNMSUBADP %vreg5<tied0>, %vreg11, %vreg5, %RM<imp-use>; VSFRC:%vreg5 F8RC:%vreg11 then the substitution makes no sense. We end up getting a crash when we try to extend the interval associated with the killed product register, as there is already a live range for %vreg5 there. This patch just disables the mutation under those circumstances. Since recipest.ll generates different code with VMX enabled, I've modified that test to use -mattr=-vsx. I've borrowed the code from that test that exposed the bug and placed it in fma-mutate.ll, where it tests several mutation opportunities including the "bad" one. llvm-svn: 220290
* [PowerPC] Change assert to better formBill Schmidt2014-10-171-3/+3
| | | | llvm-svn: 220092
* [PowerPC] Change liveness testing in VSX FMA mutation passBill Schmidt2014-10-171-8/+20
| | | | | | | | | | | | | | | | With VSX enabled, LLVM crashes when compiling test/CodeGen/PowerPC/fma.ll. I traced this to the liveness test that's revised in this patch. The interval test is designed to only work for virtual registers, but in this case the AddendSrcReg is physical. Since there is already a walk of the MIs between the AddendMI and the FMA, I added a check for def/kill of the AddendSrcReg in that loop. At Hal Finkel's request, I converted the liveness test to an assert restricted to virtual registers. I've changed the fma.ll test to have VSX and non-VSX variants so we can test both kinds of multiply-adds. llvm-svn: 220090
* Provide an implementation of getNoopForMachoTarget for PPC, otherwiseJoerg Sonnenberger2014-08-081-0/+5
| | | | | | empty functions will assert in the MC object writer. llvm-svn: 215238
* Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher2014-08-041-5/+5
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* add ppc64/pwr8 as targetWill Schmidt2014-06-261-1/+3
| | | | | | | includes handling DIR_PWR8 where appropriate The P7Model Itinerary is currently tied in for use under the P8Model, and will be updated later. llvm-svn: 211779
* The hazard recognizer only needs a subtarget, not a target machineEric Christopher2014-06-131-6/+8
| | | | | | so make it take one. Fix up all users accordingly. llvm-svn: 210948
* Remove TargetMachine from PPCInstrInfo and all dependencies andEric Christopher2014-06-121-19/+21
| | | | | | replace with the current subtarget. llvm-svn: 210836
* Avoid using subtarget features when initializing the pass pipelineEric Christopher2014-05-221-1/+12
| | | | | | on PPC. llvm-svn: 209376
* [C++11] Add 'override' keywords and remove 'virtual'. Additionally add ↵Craig Topper2014-04-291-8/+8
| | | | | | 'final' and leave 'virtual' on some methods that are marked virtual without overriding anything and have no obvious overrides themselves. PowerPC edition llvm-svn: 207504
OpenPOWER on IntegriCloud