llvm dev - Aug 2007 - [LLVMdev] c const

I guess Bill Wendling cleared it up a little more for me.  Neither llvm 
nor gcc ignore const.  The type checking in each of their frontends 
makes sure that const is not violated.

The reason I was asking about const is as follows.  I was under the 
impression that const was part of c to aid the compiler with 
optimization and not just for type checking purposes.  As you previously 
pointed out, I could get mod info from the llvm alias analysis 
interface.  However, I was thinking why go through the expense of 
computing alias analysis and bother with the imprecision of alias 
analysis, if the programmer is going to tell you that the memory pointed 
to by a pointer argument is never written.

Chris Lattner wrote:
> I don't follow what you mean - gcc doesn't ignore const and llvm  
> doesn't deviate from gcc nor from the relevant language standards.   
> Note that if you declare a global as const that we do capture this in  
> the ir - what specifically do you want?  Please provide an example.
> 
> -Chris
> 
> http://nondot.org/sabre
> http://llvm.org
> 
> On Aug 14, 2007, at 11:58 PM, "Ryan M. Lefever"  
> <lefever at crhc.uiuc.edu> wrote:
> 
> 
>>I don't mean to be a pain, but I was thinking about this a bit more.
>>Does gcc ignore the const keyword?  If not, why has LLVM chosen to
>>deviate from gcc with respect to the const keyword?  If so, then why  
>>do
>>we bother using const in LLVM API code?  I'm just curious and wanted
>>to
>>understand the thinking behind not preserving const.
>>
>>Thanks,
>>Ryan
>>
>>Chris Lattner wrote:
>>
>>>This property isn't preserved on the llvm ir, because const can
>>>always
>>>be cast away.  If you want mod information, then I suggest using the
>>>aliasanalysis interface to get mod ref info for a call.
>>>
>>>-Chris
>>>
>>>http://nondot.org/sabre
>>>http://llvm.org
>>>
>>>On Aug 8, 2007, at 12:07 AM, "Ryan M. Lefever"  
>>><lefever at crhc.uiuc.edu>
>>>wrote:
>>>
>>>
>>>
>>>>How is c's const keyword translated when compiling c into
llvm
>>>>bytecode.
>>>>I'm specifically interested in const pointer function
arguments.
>>>>Consider a function declared as follows in c:
>>>>
>>>>void f(const int* arg);
>>>>
>>>>When I examine f in llvm bytecode, how can I tell that arg is a
>>>>pointer,
>>>>whose contents can only be read, not written.
>>>>
>>>>Regards,
>>>>Ryan
>>>>_______________________________________________
>>>>LLVM Developers mailing list
>>>>LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>>_______________________________________________
>>>LLVM Developers mailing list
>>>LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>-- 
>>Ryan M. Lefever  [http://www.crhc.uiuc.edu/~lefever/index.html]
>>_______________________________________________
>>LLVM Developers mailing list
>>LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-- 
Ryan M. Lefever  [http://www.crhc.uiuc.edu/~lefever/index.html]

> if the programmer is going to tell you that the memory pointed
> to by a pointer argument is never written.
There are ways to cast away a const.

On Aug 16, 2007, at 06:05, Holger Schurig wrote:
>> if the programmer is going to tell you that the memory pointed to  
>> by a pointer argument is never written.
>
> There are ways to cast away a const.
Even if there weren't, a const value can change, just not through a  
const reference. Consider this code:

   int counter = 0;
   bool f(const int *ci) {
     int i = *ci;
     counter++;
     return *ci == i;
   }

Naively, it seems trivial to observe *ci is const and i == *ci,  
therefore i == *ci is always true:

   int counter = 0;
   bool f(const int *ci) {
     counter++;
     return true;
   }

However, that is a miscompilation since ci and &counter may alias:

   f(&counter); // must return false

So even in the absence of const_cast, most uses of const are not very  
useful for optimizers. As has been pointed out, alias analysis  
provides similar data that can be used for optimization.

— Gordon

On Thu, 16 Aug 2007, Holger Schurig wrote:
>> if the programmer is going to tell you that the memory pointed
>> to by a pointer argument is never written.
>
> There are ways to cast away a const.
You don't even need casts:

void foo(const int *P, int *Q) {
   x = *P;
   *Q = 1;
   y = *P   // redundant?
}

void bar() {
   int X = 0;
   foo(&X, &X);
}

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/