[llvm-commits] [llvm] r119455 - in /llvm/trunk: include/llvm/Analysis/ScalarEvolution.h include/llvm/Support/ConstantRange.h lib/Analysis/ScalarEvolution.cpp

[Dan Gohman]

On Nov 16, 2010, at 9:42 PM, Chris Lattner <clattner at apple.com> wrote:

>
> On Nov 16, 2010, at 9:04 PM, Nick Lewycky wrote:
>
>> Dan Gohman wrote:
>>> Modified: llvm/trunk/include/llvm/Support/ConstantRange.h
>>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Support/ConstantRange.h?rev=119455&r1=119454&r2=119455&view=diff
>>> ===
>>> ===
>>> ===
>>> ===
>>> ==================================================================
>>> --- llvm/trunk/include/llvm/Support/ConstantRange.h (original)
>>> +++ llvm/trunk/include/llvm/Support/ConstantRange.h Tue Nov 16  
>>> 20:44:44 2010
>>> @@ -47,6 +47,9 @@
>>>   ///
>>>   explicit ConstantRange(uint32_t BitWidth, bool isFullSet = true);
>>>
>>> +  /// Default constructor that creates an uninitialized  
>>> ConstantRange.
>>> +  ConstantRange() {}
>>> +
>>
>> Ugh.
>>
>> If you're going to do this, could we make it at least initialize  
>> itself
>> to a known "uninitialized" state, even if in DEBUG mode only? Any  
>> value
>> where L == U but not full or empty will do. The operations would all
>> then start with a debugInitialized() call whose implementation is #if
>> 0'd to nothing in an optimized build. Does that sound reasonable?

Yes, I'll take a look.

> Why not have a static getUninitRange() method or something?  Why are  
> uninit ranges useful?

Operator[] on DenseMap, std::map, etc. is convenient, and it requires  
a default ctor.  Perhaps it would be better to avoid this though.

Dan