summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/PowerPC/PPCTargetTransformInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Add final and owerride keywords to TargetTransformInfo's subclasses.Juergen Ributzka2014-01-241-15/+17
| | | | llvm-svn: 200021
* Re-sort all of the includes with ./utils/sort_includes.py so thatChandler Carruth2014-01-071-1/+1
| | | | | | | | | | subsequent changes are easier to review. About to fix some layering issues, and wanted to separate out the necessary churn. Also comment and sink the include of "Windows.h" in three .inc files to match the usage in Memory.inc. llvm-svn: 198685
* Implement TTI getUnrollingPreferences for PowerPCHal Finkel2013-09-111-0/+9
| | | | | | | | The PowerPC A2 core greatly benefits from aggressive concatenation unrolling; use the new getUnrollingPreferences to enable this by default when targeting the PPC A2 core. llvm-svn: 190549
* CostModel: Add parameter to instruction cost to further classify operand valuesArnold Schwaighofer2013-04-041-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | On certain architectures we can support efficient vectorized version of instructions if the operand value is uniform (splat) or a constant scalar. An example of this is a vector shift on x86. We can efficiently support for (i = 0 ; i < ; i += 4) w[0:3] = v[0:3] << <2, 2, 2, 2> but not for (i = 0; i < ; i += 4) w[0:3] = v[0:3] << x[0:3] This patch adds a parameter to getArithmeticInstrCost to further qualify operand values as uniform or uniform constant. Targets can then choose to return a different cost for instructions with such operand values. A follow-up commit will test this feature on x86. radar://13576547 llvm-svn: 178807
* Add the PPC64 popcntd instructionHal Finkel2013-03-281-3/+2
| | | | | | | 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
* Refine fix to bug 15041.Bill Schmidt2013-02-081-18/+17
| | | | | | | | | Thanks to help from Nadav and Hal, I have a more reasonable (and even correct!) approach. This specifically penalizes the insertelement and extractelement operations for the performance hit that will occur on PowerPC processors. llvm-svn: 174725
* Constrain PowerPC autovectorization to fix bug 15041.Bill Schmidt2013-02-071-0/+19
| | | | | | | | | | | | | Certain vector operations don't vectorize well with the current PowerPC implementation. Element insert/extract performs poorly without VSX support because Altivec requires going through memory. SREM, UREM, and VSELECT all produce bad scalar code. There's a lot of work to do for the cost model before autovectorization will be tuned well, and this is not an attempt to address the larger problem. llvm-svn: 174660
* Remove unused variables, silences -Wunused-variableDmitri Gribenko2013-01-251-4/+2
| | | | llvm-svn: 173526
* Initial implementation of PPCTargetTransformInfoHal Finkel2013-01-251-0/+220
This provides a place to add customized operation cost information and control some other target-specific IR-level transformations. The only non-trivial logic in this checkin assigns a higher cost to unaligned loads and stores (covered by the included test case). llvm-svn: 173520
OpenPOWER on IntegriCloud