[polly] r270409 - [FIX] Let ScalarEvolution forget hoisted values

[Tobias Grosser via llvm-commits]

On 06/08/2016 11:04 AM, Johannes Doerfert wrote:
> On 06/07, Tobias Grosser wrote:
>> On 05/23/2016 11:02 AM, Johannes Doerfert via llvm-commits wrote:
>>> Author: jdoerfert
>>> Date: Mon May 23 04:02:54 2016
>>> New Revision: 270409
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=270409&view=rev
>>> Log:
>>> [FIX] Let ScalarEvolution forget hoisted values
>>>
>>>   We have to rethink the handling of escaping values in order to make
>>>   this kind of "fixes" go away.
>>
>> CCing Utpal.
>>
>> This is one of the reasons why a function level Polly that first builds
>> up all scops and then code-generates them one by one is problematic. If
>> this value is now used in the other SCoP, we may (or may not?) get into
>> trouble. As you are working towards this goal, it will be good to keep
>> this in mind.
> The problem is that we use a caching ScalarEvolution (or ScalarEvolution
> int the first place). Your argument doesn't really apply as we see such
> problems __even though__ we do not build all SCoPs first. We might have
> some of them with a function level Polly but we have them now too.

You are right, the use of ScalarEvolution requires us to be careful when
invalidating values. When ether and me decided to use ScalarEvolution we
have been very careful in not invalidating values for which we still
reference a ScalarEvolution and to properly invalidate ScalarEvolution
values after code generation. We may have missed some cases and new code
such as LICM may have been added with me failing to pointing out the
importance of this. Still, as long as we use ScalarEvolution it is -- as
you pointed out -- important to keep this up-to-date. For a single SCoP
a time approach I am reasonable confident that we can fix upcoming
issues one-by-one, as you just did.

Now, I see two important points you make:

1) Updating SCEV is difficult

This is true and it seems you suggest that we should not use SCEV or in
general any kind of caching. I currently believe that using SCEV is the
best option as it has a lot of hardcoded knowledge which we would need
to duplicate if working directly on IR. Nevertheless, if you have better
options in mind (working directly on the IR?) we could probably open a
discussion on polly-dev.

2) ScalarEvolution and FunctionPasses

My comment was not meant to discourage you guys from going in this
direction. The only point I wanted to make is that we should keep this
issue in mind when exploring function passes. When you and Utpal move
along with this project, we can at the necessary point in time discuss
this topic.

Best,
Tobias