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

Nick Lewycky nicholas at mxc.ca
Mon Oct 24 20:57:08 PDT 2011


David Blaikie wrote:
> 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?

Sure, that'd be better. However, turning this into unreachable will be 
rather difficult.

   (&  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)

No, and please please don't do this. Doing this would mean that which 
warnings you get will vary with whether you run -O0 or -O2. It means 
that changing code in a library header will affect inlining decisions 
and cause new warnings (or removal of warnings) over there. It breaks 
users trying to use -Wall (raises hand) and erodes the user's confidence 
in the sanity of the compiler warnings.

This is what the Clang static analysis bits are for.

Nick



More information about the llvm-commits mailing list