summaryrefslogtreecommitdiffstats
path: root/llvm/test/Analysis/CostModel/PowerPC/insert_extract.ll
Commit message (Collapse)AuthorAgeFilesLines
* Recommit [PowerPC] Update P9 vector costs for insert/extractRoland Froese2019-08-261-24/+24
| | | | | | | Now that the v1i128 smin regression has been fixed, recommit the P9 cost updates from D60160. llvm-svn: 369952
* Revert Recommit [PowerPC] Update P9 vector costs for insert/extract elementJordan Rupprecht2019-07-011-24/+24
| | | | | | | | This reverts r364557 (git commit 9f7f5858fe46b8e706e87a83e2fd0a2678be619e) This crashes as reported on the commit thread. Repro instructions TBD. llvm-svn: 364876
* Recommit [PowerPC] Update P9 vector costs for insert/extract elementRoland Froese2019-06-271-24/+24
| | | | | | Recommit patch D60160 after regression fix patch D63463. llvm-svn: 364557
* Revert "[llvm] r359313 - [PowerPC] Update P9 vector costs for insert/extract ↵David L. Jones2019-05-011-24/+24
| | | | | | | | element" This causes segfaults during optimized builds. More details, including a reproducer, are on the llvm-commits thread for r359313. llvm-svn: 359648
* [PowerPC] Update P9 vector costs for insert/extract elementRoland Froese2019-04-261-24/+24
| | | | | | | | | | | The PPC vector cost model values for insert/extract element reflect older processors that lacked vector insert/extract and move-to/move-from VSR instructions. Update getVectorInstrCost to give appropriate values for when the newer instructions are present. Differential Revision: https://reviews.llvm.org/D60160 llvm-svn: 359313
* [PowerPC] Add some PPC vec cost tests to prep for D60160 NFCRoland Froese2019-04-181-1/+172
| | | | llvm-svn: 358699
* [PowerPC] Adjust load/store costs in PPCTTIHal Finkel2014-04-041-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | This provides more realistic costs for the insert/extractelement instructions (which are load/store pairs), accounts for the cheap unaligned Altivec load sequence, and for unaligned VSX load/stores. Bad news: MultiSource/Applications/sgefa/sgefa - 35% slowdown (this will require more investigation) SingleSource/Benchmarks/McGill/queens - 20% slowdown (we no longer vectorize this, but it was a constant store that was scalarized) MultiSource/Benchmarks/FreeBench/pcompress2/pcompress2 - 2% slowdown Good news: SingleSource/Benchmarks/Shootout/ary3 - 54% speedup SingleSource/Benchmarks/Shootout-C++/ary - 40% speedup MultiSource/Benchmarks/Ptrdist/ks/ks - 35% speedup MultiSource/Benchmarks/FreeBench/neural/neural - 30% speedup MultiSource/Benchmarks/TSVC/Symbolics-flt/Symbolics-flt - 20% speedup Unfortunately, estimating the costs of the stack-based scalarization sequences is hard, and adjusting these costs is like a game of whac-a-mole :( I'll revisit this again after we have better codegen for vector extloads and truncstores and unaligned load/stores. llvm-svn: 205658
* Refine fix to bug 15041.Bill Schmidt2013-02-081-0/+16
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
OpenPOWER on IntegriCloud