[llvm-commits] [llvm] r117070 - /llvm/trunk/lib/Analysis/TypeBasedAliasAnalysis.cpp

[Dan Gohman]

On Oct 22, 2010, at 1:40 PM, John McCall wrote:

> 
> On Oct 22, 2010, at 7:05 AM, Duncan Sands wrote:
> 
>> Hi Dan,
>> 
>>> // If the third field is present, it's an integer which if equal to 1
>>> -// indicates that the type is "constant" (meaning
>>> -// pointsToConstantMemory should return true; see
>>> +// indicates that the type is "constant" (meaning pointsToConstantMemory
>>> +// should return true; see
>>> // http://llvm.org/docs/AliasAnalysis.html#OtherItfs).
>> 
>> is this "constant" field actually useful?  How are you imagining that it will
>> be used?  Even in Ada, which has a pretty strong type system and notions of
>> constantness, the fact that you have a view of an object via a constant type
>> doesn't mean that the object can't be altered, it just means it can't be
>> altered via this view.  In C, this is something like saying: suppose the
>> address of an int is held in a "const int*", then you can't alter the int via
>> this pointer; but you can always alter it by putting the address of the int in
>> a "int *" and using that instead.  So the fact that you have a "const int*"
>> doesn't mean you that it is valid for pointsToConstantMemory to return true.
> 
> Both C and C++ say that modifying an object defined with a const qualifier
> has undefined results, so while you can't use this for pointer-to-const, you
> could use it for const variables after they've been initialized.


For pointsToConstantMemory, it has to be really constant, so in C, the only
thing that could use it is statically initialized const variables.

LLVM already has constant GlobalVariables, so probably the only new
theoretical functionality here for C and C++ would be for statically initialized
objects which are mostly const but have mutable fields.

For other languages, this feature could be used for runtime library calls
which allocate objects and initialize some thereafter-constant fields in
the objects, as long as the calls are never inlined.

Dan