[llvm-commits] [llvm] r142731 - in /llvm/trunk: lib/Analysis/ScalarEvolution.cpp test/Analysis/ScalarEvolution/load.ll

[David Blaikie]

On Mon, Oct 24, 2011 at 11:14 AM, David Blaikie <dblaikie at gmail.com> wrote:
>> Make SCEV's brute force analysis stronger in two ways. Firstly, we should be
>> able to constant fold load instructions where the argument is a constant.
>> Second, we should be able to watch multiple PHI nodes through the loop; this
>> patch only supports PHIs in loop headers, more can be done here.
>>
>> With this patch, we now constant evaluate:
>>  static const int arr[] = {1, 2, 3, 4, 5};
>>  int test() {
>>    int sum = 0;
>>    for (int i = 0; i < 5; ++i) sum += arr[i];
>>    return sum;
>>  }
>
> [I'll test this myself this evening, but I thought this might be worth
> asking/discussing]
>
> What happens if you invoke UB in this code by, say, iterating past the
> end of the array? Does SCEV act on this in any way, such as replacing
> the whole block with unreachable? Would it be possible to produce a
> diagnostic of some kind? (I realize once LLVM's doing codegen it's a
> bit late for front ends, but I don't know if there are any hooks for
> such functionality)

So this currently produces a "return i32 undef" as the body of the
test() function given above. This is a bit generous - the value is
more than undefined, it invokes undefined behavior to compute it
(granted undef is one such possible UB). Would it be better to mark it
as unreachable?  (& I'm still curious if there's any precedent/way for
the llvm backend to emit warnings/errors through the clang (or other)
front ends, though I can see how that might not be entirely practical
given various optimizations, inlining, etc such that the source of
this UB was not directly correlated with the input)

- David