[llvm-dev] Scalar Evolution Expressions Involving Sibling Loops

[Philip Reames via llvm-dev]

On 3/30/20 11:27 AM, Bardia Mahjour via llvm-dev wrote:
>
> Forwarding to the dev list, in case others ran into similar issues 
> and/or have input on this topic.
>
> Bardia Mahjour
>
> ----- Forwarded by Bardia Mahjour/Toronto/IBMon 2020/03/30 02:25 PM-----
>
> From: Bardia Mahjour/Toronto/IBM
> To: listmail at philipreames.com
> Cc: "Michael Kruse" <llvm at meinersbur.de>
> Date: 2020/03/26 11:47 AM
> Subject: Scalar Evolution Expressions Involving Sibling Loops
>
> ------------------------------------------------------------------------
>
>
> Hi Philip,
>
> I hope you are doing well.
>
> We've recently run into an issue with SCEV in the context of 
> dependence analysis, and would like your opinion on it. Background 
> discussion can be found here 
> https://reviews.llvm.org/D75628#inline-689527.
>
> Basically in this case, the dependence equation requires us to 
> symbolically create an expression involving two or more recurrences 
> that recur with non-dominating loops (sibling loops). 
I'm not following your example.  If you have two sibling loops with the 
same parent, one will frequently, but not always dominate the other.  
Can you give a specific example of when forming a recurrence between two 
siblings (without one dominating the other), is useful?
> Currently creating such a SCEV expression trips asserts in 
> `CompareSCEVComplexity()` and `isKnownViaInduction()` saying that a 
> given SCEV expression cannot be composed of recurrences that have no 
> dominance relationship between them.
>
> Michael tried explaining to me why there is this restriction about 
> dominance, and I'm beginning to understand why such restriction may be 
> necessary when evaluating or expanding SCEV expressions in outer 
> scopes (eg. `getSCEVAtScope(nullptr)`) but I still don't understand 
> why this restriction is imposed at construction. Shouldn't this 
> restriction be asserted on when calling getSCEVAtScope instead of when 
> creating AddRecs, given that simplification steps may remove identical 
> terms involving non-dominating loops?
Well, SCEV construction is generally done to parallel IR.  SSA requires 
dominance, so having the SCEV operands require dominance would seem like 
a reasonable thing.  If you want to change this, you'll need to motivate 
the change.  (i.e. see above question)
>
> We would appreciate any other insight you might have about this issue.
>
> Regards,
>
> Bardia Mahjour
> Compiler Optimizations
> IBM Toronto Software Lab
> bmahjour at ca.ibm.com
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200330/44c533e6/attachment-0001.html>