This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: complete_unrolli / complete_unroll
- From: David Edelsohn <dje dot gcc at gmail dot com>
- To: Richard Guenther <richard dot guenther at gmail dot com>
- Cc: Albert Cohen <Albert dot Cohen at inria dot fr>, gcc at gcc dot gnu dot org
- Date: Tue, 29 Sep 2009 14:23:49 -0400
- Subject: Re: complete_unrolli / complete_unroll
- References: <E1MdhYW-0005WQ-00.aserg2004-list-ru@f143.mail.ru> <4A8BE7B2.7080708@inria.fr> <84fc9c000908190507x708772cdueb8193a0ff7517aa@mail.gmail.com> <4A8BFF5F.5070708@inria.fr> <4A8C0405.9030008@inria.fr> <84fc9c000908190656p7ec6cc4aja93ff860a5f61960@mail.gmail.com> <84fc9c000908190658k23a13034s64cac8be7b2de827@mail.gmail.com> <4A8CA4BC.4020807@inria.fr> <84fc9c000908200148p57979f3cp5e440f778b8fc484@mail.gmail.com>
On Thu, Aug 20, 2009 at 4:48 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> Can't we use graphite to re-roll loops? ?That is, compress the
> polyhedron by introducing a new parameter? ?But maybe I am
> not good at guessing what your initial bloat issue looks like.
>
> The reason I'm asking is that there is enough code out in the
> wild that has loops with manually unrolled bodies - I have seen
> up to 16 times here.
Do we want to try to address this partially in GCC 4.5? Providing
some way to disable early unrolling either explicitly or implicitly
when Graphite is enabled?
Early unrolling can cause two problems:
1) Increase the size of SCoPs, which increases memory consumption and
analysis time.
2) Confusing SCoP analysis.
Separate from re-rolling and other long-term solutions, it would be
helpful for Graphite if there was some explicit control over early
unrolling to help with experimentation.
Thanks, David