On Thu, 28 Sep 2017, Sebastian Pop wrote: > On Wed, Sep 27, 2017 at 6:51 AM, Richard Biener <rguent...@suse.de> wrote: > > > > The following is to allow making --param graphite-max-arrays-per-scop > > unbounded. That's a little tricky because the bound is used when > > computing "alias-sets" for scalar constraints. There's an easy way > > out though as we know the maximum alias-set assigned in the SCOP, > > we only have to remember it. The advantage (if it matters at all) > > is that we avoid a constraint coefficient gap between that last > > used alias-set and the former PARAM_GRAPHITE_MAX_ARRAYS_PER_SCOP. > > > > Bootstrap and regtest running on x86_64-unknown-linux-gnu, SPEC CPU 2006 > > tested. Will apply after testing finished. > > > > Richard. > > > > 2017-09-27 Richard Biener <rguent...@suse.de> > > > > * graphite.h (scop::max_alias_set): New member. > > * graphite-scop-detection.c: Remove references to non-existing > > --param in comments. > > (build_alias_sets): Record the maximum alias set used for drs. > > (build_scops): Support zero as unlimited for > > --param graphite-max-arrays-per-scop. > > * graphite-sese-to-poly.c (add_scalar_version_numbers): Remove > > and inline into ... > > (build_poly_sr_1): ... here. Compute alias set based on the > > maximum alias set used for drs rather than > > PARAM_GRAPHITE_MAX_ARRAYS_PER_SCOP > > > > Maybe we should keep this limit, and instead of failing to handle > huge scops, we could stop the scop detection to expand the > scop past this limit?
Yes, I believe we should put all the checks we do to discard SCOPs at SESE region build time and try if smaller regions would fit within the limits. Of course it's hard to guess whether ISL will eventually time-out or not... Another check that kills quite many SCOPs in the end is verifying whether we can handle the dependences - unfortunately that one is necessarily quadratic in the number of DRs... (hacking this away as in if we'd do versioning on a proper condition gets us 10 times more SCOPs in SPEC CPU 2006 but only 50 more transforms because code-gen errors sky-rocket). I'm going to leave the limits in place right now as I'm shifting towards fixing existing code-gen issues at the moment. Richard.