On 03/08/2010 12:36 PM, Renato Golin wrote:> Hi Tobias,
>
>
>> What do you mean with a closed CFG?
>
> Closed region, one entry/one exit.
>
>
>>> Still, non-affine loops can be converted to affine loops in many
ways
>> How would you do this? As we use the scalar evolution analysis to
analyze
>> the loops, we do not depend on any syntactic form. Therefore to change
>> non-affine loops to affine loops, I believe it takes some heavier
>> transformations.
>
> Which can be added to Poly in a later stage, right?
There are already several passes that canonicalize loops in LLVM. And
there can be even more, also some Polly might benefit from. So I would
prefer to add passes that can be generally useful directly to LLVM and
not to Polly.
> Instead of going> through all loops again, it could use the "is not affine" flag of
poly
> and try to optimize only the needed ones.
Going through all loops is not too expensive. I would prefer to keep
passes separately. This way they can be reused easily by other passes
and the code will be easier to understand.
>> And why would something look again at code polly hast just seen?
>
> Poly simplifies the region's analysis by ruling out some things, like
> "this region is const" or "this loop is affine". Other
passes could
> benefit from such analysis to simplify their code and reduce their
> footprint.
Polly simplifies the region's analysis? I do not get this.
Polly just uses the region's analysis to get the regions. Which will be
analyzed and if they cannot be handled by polly they will be skipped.
>> At first I would start with a pass that detects if regions are clean
and a
>> polly pass that skips non clean regions. Later on I would like to
schedule
>> several cleanup passes before polly to make more regions
"clean", so that
>> the can be optimized by polly.
>
> Could that be a property of Polly? To get regions even if they aren't
> clean and clean them? That would save one extra pass...
Passes are cheap. I would like to keep anything that is not required in
a separate pass. E.g. the scalar evolution analysis also only works well
if a specific set of loop transformations was done upfront. However
these transformations are separate passes that have to be scheduled
explicitly to enable scalar evolution to calculate anything.
> Maybe I'm completely wrong on assuming that Poly will generate (and
> keep) all these metadata on the regions that could be used by other
> passes, and that is where the confusion started...
Polly does not generate metadata itself. However on the way to Polly
(which is yet in an early stage) several passes have to be written. Some
of them will collect this metadata. Some of them will prepare regions
for polly. Some might create the polyhedral information. Some will
optimize this information. And some will generate optimized code /
parallel code. ...
Tobi