[LLVMdev] ScalarEvolution::createNodeForPHI

[Michele Scandale]

On 10/03/2013 09:59 PM, Hal Finkel wrote:
> ----- 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
> 

This is interesting, I was thinking to something more lightweight focused only
on loop control variables, in order to exploits constraints that with the
current infrastructure are not used. BTW, I don't like too much the idea to move
the code into SSI for the analysis.

-Michele

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