On Fri, Dec 4, 2015 at 8:59 PM, Sebastian Paul Pop <[email protected]> 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:[email protected]] > Sent: Friday, December 04, 2015 12:03 PM > To: Alan Lawrence > Cc: Sebastian Pop; [email protected]; [email protected]; > [email protected] > Subject: Re: [PATCH] enable loop fusion on isl-15 > > On Dec 4, 2015, at 5:13 AM, Alan Lawrence <[email protected]> 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. >
