This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Merging Graphite to trunk
On Fri, 31 Jul 2009, Sebastian Pop wrote:
> On Fri, Jul 31, 2009 at 12:32, Sebastian Pop<sebpop@gmail.com> wrote:
> >>> Both: -fgraphite-force-parallel uses the data dependence analysis of
> >>> Graphite to detect parallel loops and uses tree-parloops.c to code
> >>> generate the parallel code.
> >>
> >> I see. I am trying to second-guess if -ftree-parallelize-all-loops
> >> wouldn't make more sense as an option here (I guess the user doesn't
> >> care at all if it uses graphite under the hood or not ...).
> >>
> > This is correct. ÂBut I don't see it happen in general for the flags
> > of GCC: even the flag that you propose contains "tree" that would be
> > useless information for a user of GCC. ÂAt least when you have
> > graphite in the name you know that you need Graphite to use it. ÂAgain
> > this is not consistent as we now have -floop-block, -floop-strip-mine,
> > and -floop-interchange. ÂThese last flags have, in my opinion, much
> > better names.
>
> What about renaming -fgraphite-force-parallel into -floop-parallelize-all?
> We could have -floop-parallelize for the version with cost model.
> These would be consistent with the flag names of the other loop transforms
> exposed from Graphite.
Certainly better than -fgraphite-force-parallel.
Richard.
> Sebastian
>
>
--
Richard Guenther <rguenther@suse.de>
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex