forked from OSchip/llvm-project
6532c20faa
The old method used by X86TTI to determine partial-unrolling thresholds was messy (because it worked by testing target features), and also would not correctly identify the target CPU if certain target features were disabled. After some discussions on IRC with Chandler et al., it was decided that the processor scheduling models were the right containers for this information (because it is often tied to special uop dispatch-buffer sizes). This does represent a small functionality change: - For generic x86-64 (which uses the SB model and, thus, will get some unrolling). - For AMD cores (because they still currently use the SB scheduling model) - For Haswell (based on benchmarking by Louis Gerbarg, it was decided to bump the default threshold to 50; we're working on a test case for this). Otherwise, nothing has changed for any other targets. The logic, however, has been moved into BasicTTI, so other targets may now also opt-in to this functionality simply by setting LoopMicroOpBufferSize in their processor model definitions. llvm-svn: 208289 |
||
|---|---|---|
| .. | ||
| already-vectorized.ll | ||
| avx1.ll | ||
| constant-vector-operand.ll | ||
| conversion-cost.ll | ||
| cost-model.ll | ||
| fp32_to_uint32-cost-model.ll | ||
| fp64_to_uint32-cost-model.ll | ||
| fp_to_sint8-cost-model.ll | ||
| gather-cost.ll | ||
| gcc-examples.ll | ||
| illegal-parallel-loop-uniform-write.ll | ||
| lit.local.cfg | ||
| metadata-enable.ll | ||
| min-trip-count-switch.ll | ||
| no-vector.ll | ||
| parallel-loops-after-reg2mem.ll | ||
| parallel-loops.ll | ||
| rauw-bug.ll | ||
| reduction-crash.ll | ||
| small-size.ll | ||
| struct-store.ll | ||
| tripcount.ll | ||
| uint64_to_fp64-cost-model.ll | ||
| unroll-pm.ll | ||
| unroll-small-loops.ll | ||
| unroll_selection.ll | ||
| vect.omp.force.ll | ||
| vect.omp.force.small-tc.ll | ||
| vector-scalar-select-cost.ll | ||
| vector_ptr_load_store.ll | ||
| vectorization-remarks.ll | ||
| x86_fp80-vector-store.ll | ||