[LLVMdev] ScalarEvolution::createNodeForPHI

[Andrew Trick]

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]).
> 
>> - 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131003/816705ad/attachment.html>