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

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

[hiraditya]

Since graphite will not modify the CFG when it does not do any optimization,
we would like to propose that graphite's polyhedral optimizer be enabled at
-O3 -fprofile-use where, compile time is of lesser concern.

gcc/ChangeLog:

2015-11-08  Aditya Kumar  <aditya.k7@samsung.com>
            Sebastian Pop  <s.pop@samsung.com>

        * graphite.c (gate_graphite_transforms): Enable graphite on -O3 -fprofile-use.
---
 gcc/graphite.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/graphite.c b/gcc/graphite.c
index 5316bc4..49595ac 100644
--- a/gcc/graphite.c
+++ b/gcc/graphite.c
@@ -383,6 +383,9 @@ gate_graphite_transforms (void)
       || flag_loop_optimize_isl)
     flag_graphite = 1;
 
+  if (optimize >= 3 && flag_profile_use)
+    flag_loop_optimize_isl = 1;
+
   return flag_graphite != 0;
 }
 
-- 
2.1.4

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

[Richard Biener]

Sorry for not replying earlier, it seems gmail eats messages sometimes
(thus also not replying to the mail directly).

You write

> Since graphite will not modify the CFG when it does not do any 
optimization,
> we would like to propose that graphite's polyhedral optimizer be enabled 
at
> -O3 -fprofile-use where, compile time is of lesser concern.

I think this is generally a good idea.  Note that for this we should
raise the minimum supported ISL version to one supporting the
timeout thingy and of course we need to make ISL a required
prerequesite for building GCC.  Which means making sure ISL builds
on all our primary and secondary host platforms (I think it does).

I'd also like to see runtime / compile-time (and code-size?) figures
for, say, SPEC CPU 2006 (with FDO of course).  Maybe also some
information on whether GRAPHITE did anything for any benchmark
in that suite (I notice GRAPHITE doesn't use the -fopt-info
machinery, aka dump_printf and friends with MSG_OPTIMIZED_LOCATIONS
or MSG_MISSED_OPTIMIZATIONS).

So please work on the above list of items.

Thanks,
Richard.

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

[VandeVondele Joost]

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.

Joost

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

[Richard Biener]

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.

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

[aditya kumar]

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.