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.
Thanks, Sebastian -----Original Message----- From: Mike Stump [mailto:mikest...@comcast.net] Sent: Friday, December 04, 2015 12:03 PM To: Alan Lawrence Cc: Sebastian Pop; seb...@gmail.com; gcc-patches@gcc.gnu.org; hiradi...@msn.com Subject: Re: [PATCH] enable loop fusion on isl-15 On Dec 4, 2015, at 5:13 AM, Alan Lawrence <alan.lawre...@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.
