Re: [PATCH] RFC: Enable graphite at -O3 -fprofile_use

[aditya kumar <hiraditya@gmail.com>]

Thanks all for supporting the idea of enabling graphite.
We would collect compile-time, performance, code-size data and let you
know. We are very positive that the compile time would have improved
on an average,
because of new scop detection algorithm.
With the new set of patches graphite does not modify the code any more
(if no optimizations have been done). This was one of the issues
discussed at the Cauldron'15.

Currently we have a couple more patches to put in before tomorrow, so
collecting the data might take another few days, if that is okay.
If we find serious regressions in any benchmark, we will address them as well.




Aditya Kumar
Compiler Engineer


On Fri, Nov 13, 2015 at 5:32 AM, Richard Biener <rguenther@suse.de> wrote:
> On Fri, 13 Nov 2015, VandeVondele  Joost wrote:
>
>> I'm all in favour of requiring isl and enabling graphite by default, but
>> would suggest to enable it with -Ofast instead.
>>
>> One reason is that certainly extracting testcases from a PGO build is
>> more difficult, and initially there will certainly be miscompiles with
>> graphite (CP2K is right now).
>>
>> Furthermore, unless graphite is particularly effective with PGO (does it
>> use average loop trip counts already?), I don't see a particular
>> connection.
>
> The reason to choose FDO was so GRAPHITE can concentrate its computing
> budget on the hot parts of a program (which profile estimation isn't
> good enough identifying), reducing its compile-time cost.
>
> -Ofast isn't supposed to enable passes over -O3 so you're suggesting
> to enable it with -O3 which I think is a bit premature.  But we can
> try doing that and revert at the end of stage3 if problems are just
> too big.
>
> Richard.