This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [GRAPHITE, PATCH] Ping: Loop unroll and jam optimization
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Mircea Namolaru <mircea dot namolaru at inria dot fr>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Tobias Grosser <tobias at grosser dot es>, Albert Cohen <albert dot cohen at inria dot fr>, Sven Verdoolaege <skimo at kotnet dot org>
- Date: Mon, 17 Nov 2014 11:02:14 +0100
- Subject: Re: [GRAPHITE, PATCH] Ping: Loop unroll and jam optimization
- Authentication-results: sourceware.org; auth=none
- References: <20141104151755 dot GA13200 at physik dot fu-berlin dot de> <545B6A4E dot 7090308 at inria dot fr> <1413233506 dot 9233395 dot 1415278366408 dot JavaMail dot zimbra at inria dot fr> <545B6F73 dot 1010809 at inria dot fr> <158837903 dot 10030807 dot 1415403125838 dot JavaMail dot zimbra at inria dot fr> <20141108092308 dot GL9355MdfPADPa at purples dot sitecomwlr2100> <2055605754 dot 344403 dot 1415718357486 dot JavaMail dot zimbra at inria dot fr> <20141111232440 dot GI9355MdfPADPa at purples dot sitecomwlr2100> <1946236345 dot 2179089 dot 1416049070123 dot JavaMail dot zimbra at inria dot fr>
On Sat, Nov 15, 2014 at 11:57 AM, Mircea Namolaru
<mircea.namolaru@inria.fr> wrote:
> The close of stage 1 is getting close (very close). Even there is not so much new code (basically
> the new code computes the separation class option for AST build), I am not sure that the patch
> qualify for stage 2.
>
> There is very nice code generated by unroll-and-jam (stride mining) for small kernels both for constant
> or non-constant bound loops, and is an argument for the new isl based code generator. Otherwise I'm afraid
> that the code generated looks very similar with the cloog generated one, an inner loop
> with bounds of min/max that GCC doesn't further optimize, preventing perceived advantages of
> strip mining (register reuse and scalar reduction, instruction scheduling etc).
>
> ok for trunk ?
New optimization flags and new params need documentation in
gcc/doc/invoke.texi.
The description of the --params suggest they provide fixed values - is
there no way to autodetect sensible values with a cost-model? I
hardly doubt that you can find two fixed values that apply for a whole
program...
Richard.
> Thanks, Mircea
>