This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC, PR66873] Use graphite for parloops
- From: Sebastian Pop <sebpop at gmail dot com>
- To: Tom de Vries <Tom_deVries at mentor dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, Thomas Schwinge <thomas at codesourcery dot com>, "gcc-patches at gnu dot org" <gcc-patches at gnu dot org>
- Date: Mon, 20 Jul 2015 18:22:39 +0000
- Subject: Re: [RFC, PR66873] Use graphite for parloops
- Authentication-results: sourceware.org; auth=none
- References: <55A6C1DF dot 1050108 at mentor dot com> <CAFiYyc02OP9go0M1ePWEgEFVTH+B_1sxSaX7m6K6GH5CsQ=CpA at mail dot gmail dot com> <87fv4owgjy dot fsf at kepler dot schwinge dot homeip dot net> <CAFiYyc2mLNFeX_==PxTUih2BYdmQ9bOG2TGuJAjUddB35_57-g at mail dot gmail dot com> <55A7935A dot 60401 at mentor dot com>
Tom de Vries wrote:
> >>>graphite dependence analysis is too slow to be enabled unconditionally.
> >>>(read: hours in some simple cases - see bugzilla)
> >>
> >>Haha, "cool"! ;-)
> >>
> >>Maybe it is still reasonable to use graphite to analyze the code inside
> >>OpenACC kernels regions -- maybe such code can reasonably be expected to
> >>not have the properties that make its analysis lengthy? So, Tom, could
> >>you please identify and check such PRs, to get an understanding of what
> >>these properties are?
> >
> >Like the one in PR62113 or 53852 or 59121.
>
> PR62113 and PR59121 do not reproduce for me on trunk.
>
> PR53852 does reproduce for me (to the point that I had to reset my laptop).
ISL has a way to count the number of operations, based on a watermark it will
output an error code that we can use to leave graphite: see documentation of
isl_ctx_set_max_operations(). With that mechanism we can set a goal for
graphite of at max (say 10% overhead) of whole compilation time.