[LLVMdev] [llvm] r184698 - Add a flag to defer vectorization into a phase after the inliner and its

Andrew Trick atrick at apple.com
Wed Jun 26 08:14:26 PDT 2013



Sent from my iPhone...

On Jun 25, 2013, at 8:14 AM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
>> 
>> 
>> 
>> On Jun 24, 2013, at 4:24 PM, Hal Finkel < hfinkel at anl.gov > wrote:
>> 
>> 
>> 
>> 
>> Indvars should ideally preserve NSW flags whenever possible. However,
>> we don't want to rely on SCEV to preserve them. SCEV expressions are
>> implicitly reassociated and uniqued in a flow-insensitive universe
>> independent of the def-use chain of values. SCEV simply can't
>> represent the flags in most cases. I think the only flag that makes
>> sense in SCEV is the no-wrap flag on a recurrence (that's
>> independent of signed/unsigned overflow).
>> 
>> Why can't SCEV keep a flow sensitive (effectively per-BB) map of
>> expressions and their original flags (and perhaps cached deduced
>> flags)? It seems like this problem is solvable within SCEV.
>> 
>> -Hal
>> 
>> I think you would have to track all the uses of each expression...
> 
> Yes, but SCEV's are flow insensitive, normalized, and uniqued, and we only need to keep track of the original flagged instructions (specifically the parent basic blocks). Combined with some caching of subsequent flags for derived expressions I think this may even be not too expensive.

Clients of SCEV need SCEV to Value mappings. But do we really need to preserve it across passes?  Invalidation is a nasty problem. We already have issues with SCEVUnknown invalidation. 

>> You can turn SCEV into an IR and inherit all the representational
>> problems inherent in llvm IR. Or you can use it as an analysis that
>> efficiently reprents only the mathematical properties of an
>> expression and is simple to work with. I think it's fantastic as an
>> analysis but really stinks at being an IR.
> 
> Agreed. Unfortunately, we do need to keep track of wrapping properties in order to generate correct code in all cases (assuming we don't want to be unduly pessimistic). I don't think that enhancing SE to deal with this will automatically drag in all of the messiness of a full IR (especially if we can just keep track of the necessary flag information 'on the side'). I also don't like the idea of writing mini-SEs all over the place to work around problems in SE.
> 
> Regardless, I take it that you feel that I'm off-base in wanting SE to deal with nsw in some general sense, but I don't see why. As you've pointed out to me, at least some SE computations assume nsw even when perhaps they shouldn't (like the backedge-taken counts). That combined with the fact that SE is dropping the flags, causing problems for downstream passes, seems like a good motivation for tracking them within SE. 

SE "drops" flags internally because we don't have a safe way to express them. But why is Indvars dropping the IR flags? We should:
1) determine if its safe for Indvars to preserve nsw in the cases we miss now   
2) if not we may want a loop level analysis to preserve certain facts like trip count (hopefully not needed)
3) defer parts of Indvars that are destructive or even reorganize loop passes. E.g.linear function test replace could as late as LSR. 

> A more general question: Currently, when we have (i +(nsw) 5) in SE, etc. implicitly assumes that (i + 25) also does not wrap, correct? If that's right, then while this seems to follow the C model, I don't think that it is specified in the language reference.

Good point. I'm sure we make that assumption in places. 
Andy

> Thanks again,
> Hal
> 
>> 
>> 
>> -Andy
> 
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory



More information about the llvm-dev mailing list