This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: complete_unrolli / complete_unroll
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: David Edelsohn <dje dot gcc at gmail dot com>
- Cc: Albert Cohen <Albert dot Cohen at inria dot fr>, gcc at gcc dot gnu dot org
- Date: Wed, 30 Sep 2009 11:06:13 +0200
- 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> <303e1d290909291123t480939f6oe83d76c7536419e1@mail.gmail.com>
On Tue, Sep 29, 2009 at 8:23 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
> 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.
I can definitely look into that - can someone open a bugreport
and assign it to me please?
Thanks,
RIchard.
> Thanks, David
>