Re: [PATCH] enable loop fusion on isl-15

[Richard Biener <richard.guenther@gmail.com>]

On Fri, Dec 4, 2015 at 8:59 PM, Sebastian Paul Pop <s.pop@samsung.com> wrote:
> I would highly recommend updating the required version of ISL to isl-0.15:
> that would simplify the existing code, removing a lot of code under "#ifdef
> old ISL",
> and allow us to fully transition to schedule_trees instead of dealing with
> the
> old antiquated union_maps in the scheudler.  The result is faster
> compilation time.

Hmm.  I think we agreed to raise the requirement to ISL 0.14.  OTOH the plan
was to make graphite enabled by -O3 [-fprofile-use] by default which would
mean making ISL a hard host requirement.  That raises the barrier on making
the version requirement stricter ...

Sebastian, were quite into stage3 already - what's your plans / progress with
the defaulting of GRPAHITE?  (compile-time / performance numbers though
I see ICEs still popping up - a good thing in some sense as it looks like
GRAPHITE gets testing).

Thanks,
Richard.

> Thanks,
> Sebastian
>
> -----Original Message-----
> From: Mike Stump [mailto:mikestump@comcast.net]
> Sent: Friday, December 04, 2015 12:03 PM
> To: Alan Lawrence
> Cc: Sebastian Pop; sebpop@gmail.com; gcc-patches@gcc.gnu.org;
> hiraditya@msn.com
> Subject: Re: [PATCH] enable loop fusion on isl-15
>
> On Dec 4, 2015, at 5:13 AM, Alan Lawrence <alan.lawrence@arm.com> wrote:
>> On 05/11/15 21:43, Sebastian Pop wrote:
>>>        * graphite-optimize-isl.c (optimize_isl): Call
>>>        isl_options_set_schedule_maximize_band_depth.
>>>
>>>        * gcc.dg/graphite/fuse-1.c: New.
>>>        * gcc.dg/graphite/fuse-2.c: New.
>>>        * gcc.dg/graphite/interchange-13.c: Remove bogus check.
>>
>> I note that the test
>>
>> scan-tree-dump-times forwprop4 "gimple_simplified to[^\\n]*\\^ 12" 1
>>
>> FAILs under isl-0.14, with which GCC can still be built and generally
> claims to work.
>>
>> Is it worth trying to detect this in the testsuite, so we can XFAIL it? By
> which I mean, is there a reasonable testsuite mechanism by which we could do
> that?
>
> You can permanently ignore it by updating to 0.15?  I don't see the
> advantage of bothering to finesse this too much.  I don't know of a way to
> detect 14 v 15 other than this test case, but, if you do that, you can't use
> that result to gate this test case.  If one wanted to engineer in a way, one
> would expose the isl version via a preprocessor symbol (built in), and then
> the test case would use that to gate it.  If we had to fix it, I think I'd
> prefer we just raise the isl version to 15 or later and be done with it.
>