This is the mail archive of the
mailing list for the GCC project.
Re: Fix scheduler ix86_issue_rate and ix86_adjust_cost for modern x86 chips
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: "Gopalasubramanian, Ganesh" <Ganesh dot Gopalasubramanian at amd dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "Uros Bizjak (ubizjak at gmail dot com)" <ubizjak at gmail dot com>, "H.J. Lu (hjl dot tools at gmail dot com)" <hjl dot tools at gmail dot com>, rguenther at suse dot de
- Date: Fri, 25 Oct 2013 14:09:45 +0200
- Subject: Re: Fix scheduler ix86_issue_rate and ix86_adjust_cost for modern x86 chips
- Authentication-results: sourceware.org; auth=none
- References: <EB4625145972F94C9680D8CADD6516155C23F184 at SATLEXDAG02 dot amd dot com> <20131024092425 dot GA13149 at atrey dot karlin dot mff dot cuni dot cz> <EB4625145972F94C9680D8CADD6516155C23F201 at SATLEXDAG02 dot amd dot com> <20131024131811 dot GC20887 at kam dot mff dot cuni dot cz> <EB4625145972F94C9680D8CADD6516155C23F8FA at SATLEXDAG02 dot amd dot com>
> > OK, so it is about 2%. Did you try if you need lookahead even in the early pass (before reload)? My guess would be so, but if not, it could cut the cost to half. For -Ofast/-O3 it looks resonable to me, but we will need to announce it on the ML. For other settings I think we need to work on more improvements or cut the expenses.
> Yes, it is required before reload.
> I have another idea which can be pondered upon. Currently, can we enable lookahead with the value 4 (pre reload) for default? This will exponentially cut the cost of build time.
> I have done some measurements on the build time of some benchmarks (mentioned below) with lookahead value 4. The 2% increase in build time with value 8 is now almost gone.
> dfa4 no_lookahead
> perlbench - 191s 193s
> bzip2 - 19s 19s
> gcc - 429s 429s
> mcf - 3s 3s
> gobmk - 116s 115s
> hmmer - 60s 60s
> sjeng - 18s 17s
> libquantum - 6s 6s
> h264ref - 107s 107s
> omnetpp - 128s 128s
> astar - 7s 7s
> bwaves - 5s 5s
> gamess - 1964s 1957s
> milc - 18s 18s
> GemsFDTD - 273s 272s
> Lookahead value 4 also helps because, the modified decoder model in bdver3.md is only two cycles deep (though in hardware it is actually 4 cycles deep). This means that we can look another two levels deep for better schedule.
> GemsFDTD still retains the performance boost of around 6-7% with value 4.
> Let me know your thoughts.
This seems resonable. I would go for lookahead of 4 for now and 8 for -Ofast
and we can tune things based on the experience with this setting incrementally.
Uros, Richard, what do you think?