search for: fp2006

...hat of BURR in both metrics. This result is surprising for me, because, as far as I understand, this scheduler is a conservative scheduler that tries to preserve the original program order, isn't it? Does this result surprise you? > > 4. The ILP scheduler has the worst execution times on FP2006 and the second worst spill counts, although it is the default on x86-64. Is this surprising? BTW, Dragon Egg sets the scheduler to source. On Line 368 in Backend.cpp, we find: > if (!flag_schedule_insns) > Args.push_back("--pre-RA-sched=source"); > > Here are the detai...

...hat of BURR in both metrics. This result is surprising for me, because, as far as I understand, this scheduler is a conservative scheduler that tries to preserve the original program order, isn't it? Does this result surprise you? > > 4. The ILP scheduler has the worst execution times on FP2006 and the second worst spill counts, although it is the default on x86-64. Is this surprising? BTW, Dragon Egg sets the scheduler to source. On Line 368 in Backend.cpp, we find: > if (!flag_schedule_insns) >    Args.push_back("--pre-RA-sched=source");  > > Here are the detail...

...close to that of BURR in both metrics. This result is surprising for me, because, as far as I understand, this scheduler is a conservative scheduler that tries to preserve the original program order, isn't it? Does this result surprise you? 4. The ILP scheduler has the worst execution times on FP2006 and the second worst spill counts, although it is the default on x86-64. Is this surprising? BTW, Dragon Egg sets the scheduler to source. On Line 368 in Backend.cpp, we find: if (!flag_schedule_insns)     Args.push_back("--pre-RA-sched=source");   Here are the details of our results:...

...t to define new heuristics should reuse ScheduleDAGMI directly and only define their own MachineSchedStrategy. > >> >> - Our SPEC testing on x86-64 has shown a significant performance improvement of LLVM 3.3 relative to LLVM 2.9 (about 5% in geomean on INT2006 and 15% in geomean on FP2006), but our spill code measurements have shown that LLVM 3.3 generates significantly more spill code on most benchmarks. We will be doing more investigation on this, but are there any known facts that explain this behavior? Is this caused by a known regression in scheduling and/or allocation (which I...

...point. Should we integrate our work (an alternate register pressure reduction scheduler) into the SD scheduler or the MI scheduler? - Our SPEC testing on x86-64 has shown a significant performance improvement of LLVM 3.3 relative to LLVM 2.9 (about 5% in geomean on INT2006 and 15% in geomean on FP2006), but our spill code measurements have shown that LLVM 3.3 generates significantly more spill code on most benchmarks. We will be doing more investigation on this, but are there any known facts that explain this behavior? Is this caused by a known regression in scheduling and/or allocation (which...

...who only want to define new heuristics should reuse ScheduleDAGMI directly and only define their own MachineSchedStrategy. > >- Our SPEC testing on x86-64 has shown a significant performance improvement of LLVM 3.3 relative to LLVM 2.9 (about 5% in geomean on INT2006 and 15% in geomean on FP2006), but our spill code measurements have shown that LLVM 3.3 generates significantly more spill code on most benchmarks. We will be doing more investigation on this, but are there any known facts that explain this behavior? Is this caused by a known regression in scheduling and/or allocation (which...

...specific micro-optimized features. Besides, hardware and software are designed nowadays based on some version of Dhrystone, EEMBC, SPEC or CoreMark, so it's not impossible to see 50% increase in performance with little changes in either. 4. The ILP scheduler has the worst execution times on FP2006 and the second > worst spill counts, although it is the default on x86-64. Is this > surprising? BTW, Dragon Egg sets the scheduler to source. On Line 368 in > Backend.cpp, we find: > if (!flag_schedule_insns) > Args.push_back("--pre-RA-sched=source"); > This looks...

...m32 option):Using -O3 -m32 only:                                               INT score: 16.86     FP score: 14.09 Using -O3 -m32 -march=core2 -mtune=core2:     INT score: 17.02     FP score: 15.24 So, there is a significant difference in this case. In fact, the 8% geometric-mean improvement on FP2006 is a huge improvement that comes out of many double-digit percentage improvements on some individual benchmarks. The biggest improvement is 48% on gromacs, which is a CPU-intensive FP benchmark. The above geometric means are consistent with the logical expectation that LLVM's performance in...

...who only want to define new heuristics should reuse ScheduleDAGMI directly and only define their own MachineSchedStrategy. > > - Our SPEC testing on x86-64 has shown a significant performance improvement of LLVM 3.3 relative to LLVM 2.9 (about 5% in geomean on INT2006 and 15% in geomean on FP2006), but our spill code measurements have shown that LLVM 3.3 generates significantly more spill code on most benchmarks. We will be doing more investigation on this, but are there any known facts that explain this behavior? Is this caused by a known regression in scheduling and/or allocation (which I...

...ith that of LLVM's default scheduler on x86 (BURR scheduler on x86-32 and ILP on x86-64) using SPEC CPU2006. The results show that our B&B scheduler significantly improves the performance of some benchmarks relative to LLVM's default scheduler by up to 21%. The geometric-mean speedup on FP2006 is about 2.4% across the entire suite. We then observed that LLVM's ILP scheduler on x86-64 uses "rough" latency values. So, we added the precise latency values published by Agner (http://www.agner.org/optimize/) and that led to more speedup relative to LLVM's ILP scheduler on so...

...gt; score: 15.24 > Note that these scores are still lower than those x86-64 got in both modes. I'm not sure why you think some optimization was enabled here rather than disabled... > So, there is a significant difference in this case. In fact, the 8% > geometric-mean improvement on FP2006 is a huge improvement that comes out > of many double-digit percentage improvements on some individual benchmarks. > The biggest improvement is 48% on gromacs, which is a CPU-intensive FP > benchmark. > I haven't tested it, but I'd be willing to bet this is a difference of usin...

...d it into LLVM 2.9 as yet-another scheduler. Our scheduler uses a combinatorial optimization approach to balance ILP and register pressure. In one experiment, we added more precise latency information for most common x86 instructions to our scheduler and noticed a 10% performance improvement on one FP2006 benchmark, namely gromacs. More precisely, we compared: (1) LLVM2.9+ourScheduler+preciseLatency against (2) LLVM2.9+ourScheduler+LLVM's-rough-1-10-latency-model And (1) was faster than (2) by 10%. We concluded that adding precise latency information may significantly improve the perform...

...ith that of LLVM's default scheduler on x86 (BURR scheduler on x86-32 and ILP on x86-64) using SPEC CPU2006. The results show that our B&B scheduler significantly improves the performance of some benchmarks relative to LLVM's default scheduler by up to 21%. The geometric-mean speedup on FP2006 is about 2.4% across the entire suite. We then observed that LLVM's ILP scheduler on x86-64 uses "rough" latency values. So, we added the precise latency values published by Agner (http://www.agner.org/optimize/) and that led to more speedup relative to LLVM's ILP scheduler on som...

...d it into LLVM 2.9 as yet-another scheduler. Our scheduler uses a combinatorial optimization approach to balance ILP and register pressure. In one experiment, we added more precise latency information for most common x86 instructions to our scheduler and noticed a 10% performance improvement on one FP2006 benchmark, namely gromacs. More precisely, we compared: > > (1) LLVM2.9+ourScheduler+preciseLatency > against > (2) LLVM2.9+ourScheduler+LLVM's-rough-1-10-latency-model > > And (1) was faster than (2) by 10%. We concluded that adding precise latency information may signif...

...; LLVM's default scheduler by up to 21%. ... are these differences statistically significant? In my experience SPEC scores can vary considerably on different runs, so how many runs did you do and what was the estimated standard deviation? Best wishes, Duncan. The geometric-mean speedup on FP2006 is > about 2.4% across the entire suite. We then observed that LLVM's ILP scheduler > on x86-64 uses "rough" latency values. So, we added the precise latency values > published by Agner (http://www.agner.org/optimize/) and that led to more speedup > relative to LLVM's...

Which options are you seeing that cause the largest difference, and on which targets? As Chandler mentioned there has been a large amount of variation in x86 targets, and there are certain optimizations that can be done, on say a Pentium (scheduling instructions which are pairable and non-dependent so the U and V pipelines are saturated without contention, for example) that don't make sense

I have been doing some benchmarking on x86 using llvm 2.9 with the llvm-gcc 4.2 front end. I noticed that the -march and -mtune options make a significant positive difference in x86-32 mode but hardly make any difference in x86-64 mode. The small difference that I am measuring when the target is x86-64 could easily be random variation, while for the x86-32 target I am measuring a huge difference

...d it into LLVM 2.9 as yet-another scheduler. Our scheduler uses a combinatorial optimization approach to balance ILP and register pressure. In one experiment, we added more precise latency information for most common x86 instructions to our scheduler and noticed a 10% performance improvement on one FP2006 benchmark, namely gromacs. More precisely, we compared: > > >(1) LLVM2.9+ourScheduler+preciseLatency > >against > >(2) LLVM2.9+ourScheduler+LLVM's-rough-1-10-latency-model > > > >And (1) was faster than (2) by 10%. We concluded that adding precise latency inf...

On Sep 17, 2011, at 10:07 AM, Ghassan Shobaki wrote: > Hi, > > I am currently writing a paper documenting a research project that we have done on pre-allocation instruction scheduling to balance ILP and register pressure. In the paper we compare the pre-allocation scheduler that we have developed to LLVM's default schedulers for two targets: x86-64 and x86-32. We would like to

Hi, I am currently writing a paper documenting a research project that we have done on pre-allocation instruction scheduling to balance ILP and register pressure. In the paper we compare the pre-allocation scheduler that we have developed to LLVM's default schedulers for two targets: x86-64 and x86-32. We would like to include in our paper some brief descriptions of the two LLVM