[LLVMdev] ScalarEvolution::createNodeForPHI

[Hal Finkel]

----- Original Message -----
> 
> 
> 
> 
> On Oct 3, 2013, at 11:06 AM, Michele Scandale <
> michele.scandale at gmail.com > wrote:
> 
> 
> 
> 
> My very abstract suggestion for future improvements are:
> - At the SCEV level, logic to deduce that some recurrences cannot
> wrap given a set of loop facts derived from the IR and represented
> independent from the SCEV expressions themselves.
> 
> I agree with this. I noticed that value ranges are computed
> independently from
> the "context" of the instruction related to the SCEV: for loop
> analysis we may
> exploit information from facts dominating the loop execution. Maybe
> it would be
> easier to map to a given IR Value a set of SCEV depending on the
> DomTree node we
> are considering (given a variable %x, an if-then-else on condition
> "%x slt 0",
> in one branch the range for %x would be [1, INT_MAX] in the other
> [INT_MIN, 0]).
> 

Random question: is this relevant: https://code.google.com/p/wrapped-intervals/ ?

 -Hal

> 
> 
> - At the IR level, rely on some sort of trap-on-overflow intrinsic
> independent from the arithmetic operations that can be carried
> through canonicalization, reassociation etc. This could be done
> today with existing overflow intrinsics, but modeling the trap would
> require a branch.
> 
> Why this? Do we need to handle also trapping arithmetic?
> 
> 
> The trap can be viewed as an invariant. For C, the traps can
> disappear under the undefined behavior rule and they could be
> readonly to the optimizer. I imagine other LLVM clients would want
> to materialize the traps. That doesn’t matter to me now. It’s how
> the optimizer derives information from the IR and preserves it that
> matters.
> 
> SCEV could be improved without doing this. It does potentially
> provide a better way for SCEV to discover invariants, solves the
> problem of earlier passes, like Reassociate and GVN, dropping flags,
> and allows code to be rewritten based on SCEV without losing the
> invariants.
> 
> 
> 
> 
> -Andy
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

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