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

[Hal Finkel]

----- 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.

> 
> 
> 
> 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. 

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.

Thanks again,
Hal

> 
> 
> -Andy

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory