This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: SPEC / testsuite results for disabling SFTs and the alias-oracle patches
On Wed, 5 Mar 2008, Diego Novillo wrote:
> On 03/05/08 06:48, Richard Guenther wrote:
>
> > you can see that in both cases the runs without SFTs are significantly
> > better(!) Which hints at the fact that we do a poor job with parititoning
> > and/or that partitioning triggers earlier with SFTs enabled.
>
> All these differences seem to be less than 1%. If I'm reading this table
> right, the alias oracle is not really having a significant effect on the
> scores
Yes. SPEC 2000 is probably not a very good measure for our memory
optimization capabilities. Still the oracle retains the optimizations
we test for in the testsuite and which were added as SFTs were able to
optimize them.
> > The oracle patches are able to slightly improve the results in the non-SFT
> > case, but overall there is less difference patched vs. unpatched compared
> > to the differences that result if you disable SFTs.
>
> Without the alias oracle you get:
>
> SFTs (base) No SFTs (peak)
> SPECint 1914 1927 (+0.68%)
> SPECfp 2029 2032 (+0.15%)
>
>
> With the alias oracle you get:
>
> SFTs (base) No SFTs (peak)
> SPECint 1918 1923 (+0.26%)
> SPECfp 2020 2039 (+0.94%)
>
> The good news is that the oracle is not introducing any slowdowns. So I think
> this is very positive.
Right. Especially that No SFTs doesn't introduce any slowdowns.
> > Thus, with the above results I propose we disable generating SFTs by
> > default on the mainline (--para max-fields-for-field-sensitive=100
> > is still available for comparision). I will prepare a patch to adjust
> > the false negative testcases above to check for optimization outcome
> > as well.
>
> Yes, good idea. Though I think we should just get rid of SFTs outright.
> They are only going to be a maintenance problem.
I agree, still it is probably nice to be able to compare testcase behavior
with/without SFTs with the same state of trunk for a while. So I'd just
adjust the default of --para max-fields-for-field-sensitive for now
(after the oracle patches got in) and remove the code dealing with SFTs
only after stage2. I am very positive we _will_ get some missed
optimization cases switching off SFTs and it will make our (my) life
easier in tracking them down if they were still available on demand.
Thanks,
Richard.