This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][GRAPHITE] Allow --param graphite-max-arrays-per-scop=0
On Thu, 28 Sep 2017, Sebastian Pop wrote:
> On Wed, Sep 27, 2017 at 6:51 AM, Richard Biener <rguenther@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 <rguenther@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.