Fw: [patch][wwwdocs] 4.5/changes.html: Add autopar changes

[Li Feng]

Hi Gerald,

On Thu, Nov 5, 2009 at 8:41 AM, Gerald Pfeifer <gerald@pfeifer.com> wrote:
>
> Hi Razya,
>
> On Tue, 3 Nov 2009, Razya Ladelsky wrote:
>> I documented the changes in autopar for GCC4.5.
>> Ok to commit?
>
> this looks good, thanks for taking the time to write it up.  I just
> have one question for my own understanding (which may or may not be
> relevant to consider for the change):
>
>> +    <li>The automatic parallelization pass was enhanced to support
>> +    parallelization of outer loops.</li>
>> +
>> +    <li>Automatic parallelization can be enabled as part of Graphite.
>> +    Both <code>-ftree-parallelize-loops=*</code> and
>> +    <code>-floop-parallelize-all</code>need to be turned on.</li>
>
> How does automatic parallelization relate to Graphite?  My understanding
> is that we have automatic parallelization both without Graphite and now
> with Graphite, too, and that -ftree-parallelize-loops= is the general
> option and that -floop-parallelize-all comes from Graphite.  If that
> is the case, perhaps something like "In addition to -ftree-parallelize-loops=,
> specify -floop-parallelize-all to enable the Graphite-based optimization"
> or something like that?

The autopar in trunk is based on the lambda framework for dependency checking,
while in Graphite, we have a stronger dependency analyzer based on polyhedral
model and the some other utilities, so that we could handle more than before
(e.g. in Graphite, we can handle
loops with if conditions, some triangle loops, and some loops we can deduce no-
dependency with polyhedral dependency analyzer).

So we replace the original dependency analyzer in Graphite, and still use the
code generation part in tree-parloops.c.

But still, this is only a initial work for autopar in Graphite, and
some other things
needs to be done.

>
> (Otherwise there is a blank missing before "need".)
>
> Gerald
>

Li