c const

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

c const

Ryan M. Lefever
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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: c const

Holger Schurig-2
> How is c's const keyword translated when compiling c into
> llvm bytecode.

It isn't. You can verify this quite simply with the following
test program:

void a(const void *p)
{
}

void b(void *p)
{
}



$ clang --emit-llvm test.c
; ModuleID = 'foo'

define void @a(i8* %p) {
entry:
        %p.addr = alloca i8*            ; <i8**> [#uses=1]
        %allocapt = bitcast i32 undef to i32            ; <i32> [#uses=0]
        store i8* %p, i8** %p.addr
        ret void
}

define void @b(i8* %p) {
entry:
        %p.addr = alloca i8*            ; <i8**> [#uses=1]
        %allocapt = bitcast i32 undef to i32            ; <i32> [#uses=0]
        store i8* %p, i8** %p.addr
        ret void
}



Now, I tried this with the gcc 4.0 frontend as well:

$ gcc -c --emit-llvm test.c -o - | llvm-dis -o -
; ModuleID = '<stdin>'
target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i686-pc-linux-gnu"

define void @a(i8* %p) {
entry:
        %p_addr = alloca i8*            ; <i8**> [#uses=1]
        %"alloca point" = bitcast i32 0 to i32          ; <i32> [#uses=0]
        store i8* %p, i8** %p_addr
        br label %return

return:         ; preds = %entry
        ret void
}

define void @b(i8* %p) {
entry:
        %p_addr = alloca i8*            ; <i8**> [#uses=1]
        %"alloca point" = bitcast i32 0 to i32          ; <i32> [#uses=0]
        store i8* %p, i8** %p_addr
        br label %return

return:         ; preds = %entry
        ret void
}


As you can see, with both C compilers the generated intermediate language
is the same for both function a() and b().

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: c const

Ryan M. Lefever
Thanks for the help.  I'm surprised that llvm doesn't preserve the const
property.  I thought that it was supposed to be useful for various
compiler optimizations.

Holger Schurig wrote:

>>How is c's const keyword translated when compiling c into
>>llvm bytecode.
>
>
> It isn't. You can verify this quite simply with the following
> test program:
>
> void a(const void *p)
> {
> }
>
> void b(void *p)
> {
> }
>
>
>
> $ clang --emit-llvm test.c
> ; ModuleID = 'foo'
>
> define void @a(i8* %p) {
> entry:
>         %p.addr = alloca i8*            ; <i8**> [#uses=1]
>         %allocapt = bitcast i32 undef to i32            ; <i32> [#uses=0]
>         store i8* %p, i8** %p.addr
>         ret void
> }
>
> define void @b(i8* %p) {
> entry:
>         %p.addr = alloca i8*            ; <i8**> [#uses=1]
>         %allocapt = bitcast i32 undef to i32            ; <i32> [#uses=0]
>         store i8* %p, i8** %p.addr
>         ret void
> }
>
>
>
> Now, I tried this with the gcc 4.0 frontend as well:
>
> $ gcc -c --emit-llvm test.c -o - | llvm-dis -o -
> ; ModuleID = '<stdin>'
> target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
> target triple = "i686-pc-linux-gnu"
>
> define void @a(i8* %p) {
> entry:
>         %p_addr = alloca i8*            ; <i8**> [#uses=1]
>         %"alloca point" = bitcast i32 0 to i32          ; <i32> [#uses=0]
>         store i8* %p, i8** %p_addr
>         br label %return
>
> return:         ; preds = %entry
>         ret void
> }
>
> define void @b(i8* %p) {
> entry:
>         %p_addr = alloca i8*            ; <i8**> [#uses=1]
>         %"alloca point" = bitcast i32 0 to i32          ; <i32> [#uses=0]
>         store i8* %p, i8** %p_addr
>         br label %return
>
> return:         ; preds = %entry
>         ret void
> }
>
>
> As you can see, with both C compilers the generated intermediate language
> is the same for both function a() and b().
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

--
Ryan M. Lefever  [http://www.ews.uiuc.edu/~lefever]
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: c const

Chris Lattner
In reply to this post by Ryan M. Lefever
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" <[hidden email]>  
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
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: c const

Nikhil A. Patil
Hi,

I think I found a bug. I don't know if it's in upstream gcc or llvm-gcc4.

int func()
{
    const int *arr;
    arr[0] = 1;
}

$ llvm-gcc main.c -c; echo $?
0

$ gcc main.c -c
main.c: In function 'func':
main.c:4: error: assignment of read-only location

The difference disappears when arr[0] is replaced by *arr.

(I tried the above with gcc 4.1.2, 3.4.6, 4.0.3. (I don't have access
to 4.0.1, off which llvm-gcc seems to be derived.)

nikhil

On 08/08/2007, Chris Lattner <[hidden email]> 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" <[hidden email]>
> 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
> > [hidden email]         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: c const

Chris Lattner
On Wed, 8 Aug 2007, Nikhil A. Patil wrote:
> I think I found a bug. I don't know if it's in upstream gcc or llvm-gcc4.

Looks like a bug, please file a bugzilla entry.

-Chris

> int func()
> {
>    const int *arr;
>    arr[0] = 1;
> }
>
> $ llvm-gcc main.c -c; echo $?
> 0
>
> $ gcc main.c -c
> main.c: In function 'func':
> main.c:4: error: assignment of read-only location
>
> The difference disappears when arr[0] is replaced by *arr.
>
> (I tried the above with gcc 4.1.2, 3.4.6, 4.0.3. (I don't have access
> to 4.0.1, off which llvm-gcc seems to be derived.)
>
> nikhil
>
> On 08/08/2007, Chris Lattner <[hidden email]> 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" <[hidden email]>
>> 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
>>> [hidden email]         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: c const

Daniel Berlin
This certainly doesn't occur in gcc mainline.
In fact, I improved the error message, and added a error test to gcc
just yesterday.


On 8/9/07, Chris Lattner <[hidden email]> wrote:

> On Wed, 8 Aug 2007, Nikhil A. Patil wrote:
> > I think I found a bug. I don't know if it's in upstream gcc or llvm-gcc4.
>
> Looks like a bug, please file a bugzilla entry.
>
> -Chris
>
> > int func()
> > {
> >    const int *arr;
> >    arr[0] = 1;
> > }
> >
> > $ llvm-gcc main.c -c; echo $?
> > 0
> >
> > $ gcc main.c -c
> > main.c: In function 'func':
> > main.c:4: error: assignment of read-only location
> >
> > The difference disappears when arr[0] is replaced by *arr.
> >
> > (I tried the above with gcc 4.1.2, 3.4.6, 4.0.3. (I don't have access
> > to 4.0.1, off which llvm-gcc seems to be derived.)
> >
> > nikhil
> >
> > On 08/08/2007, Chris Lattner <[hidden email]> 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" <[hidden email]>
> >> 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
> >>> [hidden email]         http://llvm.cs.uiuc.edu
> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> [hidden email]         http://llvm.cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >>
> > _______________________________________________
> > LLVM Developers mailing list
> > [hidden email]         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
>
> -Chris
>
> --
> http://nondot.org/sabre/
> http://llvm.org/
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: c const

Chris Lattner
On Thu, 9 Aug 2007, Daniel Berlin wrote:
> This certainly doesn't occur in gcc mainline.
> In fact, I improved the error message, and added a error test to gcc
> just yesterday.

Yep, clang reports:

t.c:4:12: error: read-only variable is not assignable
     arr[0] = 1;
     ~~~~~~ ^
1 diagnostic generated.

so this is specific to llvm-gcc somehow.

-Chris

> On 8/9/07, Chris Lattner <[hidden email]> wrote:
>> On Wed, 8 Aug 2007, Nikhil A. Patil wrote:
>>> I think I found a bug. I don't know if it's in upstream gcc or llvm-gcc4.
>>
>> Looks like a bug, please file a bugzilla entry.
>>
>> -Chris
>>
>>> int func()
>>> {
>>>    const int *arr;
>>>    arr[0] = 1;
>>> }
>>>
>>> $ llvm-gcc main.c -c; echo $?
>>> 0
>>>
>>> $ gcc main.c -c
>>> main.c: In function 'func':
>>> main.c:4: error: assignment of read-only location
>>>
>>> The difference disappears when arr[0] is replaced by *arr.
>>>
>>> (I tried the above with gcc 4.1.2, 3.4.6, 4.0.3. (I don't have access
>>> to 4.0.1, off which llvm-gcc seems to be derived.)
>>>
>>> nikhil
>>>
>>> On 08/08/2007, Chris Lattner <[hidden email]> 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" <[hidden email]>
>>>> 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
>>>>> [hidden email]         http://llvm.cs.uiuc.edu
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> [hidden email]         http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> [hidden email]         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>
>> -Chris
>>
>> --
>> http://nondot.org/sabre/
>> http://llvm.org/
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: c const

Nikhil A. Patil
I have filed the bug, and added your comments.
    http://llvm.org/bugs/show_bug.cgi?id=1603

nikhil

On 09/08/07, Chris Lattner <[hidden email]> wrote:

> On Thu, 9 Aug 2007, Daniel Berlin wrote:
> > This certainly doesn't occur in gcc mainline.
> > In fact, I improved the error message, and added a error test to gcc
> > just yesterday.
>
> Yep, clang reports:
>
> t.c:4:12: error: read-only variable is not assignable
>      arr[0] = 1;
>      ~~~~~~ ^
> 1 diagnostic generated.
>
> so this is specific to llvm-gcc somehow.
>
> -Chris
>
> > On 8/9/07, Chris Lattner <[hidden email]> wrote:
> >> On Wed, 8 Aug 2007, Nikhil A. Patil wrote:
> >>> I think I found a bug. I don't know if it's in upstream gcc or llvm-gcc4.
> >>
> >> Looks like a bug, please file a bugzilla entry.
> >>
> >> -Chris
> >>
> >>> int func()
> >>> {
> >>>    const int *arr;
> >>>    arr[0] = 1;
> >>> }
> >>>
> >>> $ llvm-gcc main.c -c; echo $?
> >>> 0
> >>>
> >>> $ gcc main.c -c
> >>> main.c: In function 'func':
> >>> main.c:4: error: assignment of read-only location
> >>>
> >>> The difference disappears when arr[0] is replaced by *arr.
> >>>
> >>> (I tried the above with gcc 4.1.2, 3.4.6, 4.0.3. (I don't have access
> >>> to 4.0.1, off which llvm-gcc seems to be derived.)
> >>>
> >>> nikhil
> >>>
> >>> On 08/08/2007, Chris Lattner <[hidden email]> 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" <[hidden email]>
> >>>> 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
> >>>>> [hidden email]         http://llvm.cs.uiuc.edu
> >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >>>> _______________________________________________
> >>>> LLVM Developers mailing list
> >>>> [hidden email]         http://llvm.cs.uiuc.edu
> >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >>>>
> >>> _______________________________________________
> >>> LLVM Developers mailing list
> >>> [hidden email]         http://llvm.cs.uiuc.edu
> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >>>
> >>
> >> -Chris
> >>
> >> --
> >> http://nondot.org/sabre/
> >> http://llvm.org/
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> [hidden email]         http://llvm.cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >>
> > _______________________________________________
> > LLVM Developers mailing list
> > [hidden email]         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
>
> -Chris
>
> --
> http://nondot.org/sabre/
> http://llvm.org/
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: c const

Ryan M. Lefever
In reply to this post by Chris Lattner
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" <[hidden email]>  
> 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
>>[hidden email]         http://llvm.cs.uiuc.edu
>>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: c const

Bill Wendling
Constness is preserved by the front-end. It's the front-end's job to  
check that a "const" attribute for a language (and its meaning  
differs among them) is used correctly according to the semantics of  
that language. So, if you have a language that prevents you from  
assigning a value to a const variable, then there will never be an  
assignment to that variable in LLVM's IR.

-bw

On Aug 14, 2007, at 11:58 PM, Ryan M. Lefever 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"  
>> <[hidden email]>
>> 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
>>> [hidden email]         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]         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
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: c const

Chris Lattner
In reply to this post by Ryan M. Lefever
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"  
<[hidden email]> 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"  
>> <[hidden email]>
>> 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
>>> [hidden email]         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]         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
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: c const

Ryan M. Lefever
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"  
> <[hidden email]> 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"  
>>><[hidden email]>
>>>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
>>>>[hidden email]         http://llvm.cs.uiuc.edu
>>>>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>>_______________________________________________
>>>LLVM Developers mailing list
>>>[hidden email]         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
>>[hidden email]         http://llvm.cs.uiuc.edu
>>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: c const

Holger Schurig-2
> 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.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: c const

Gordon Henriksen-3
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


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: c const

Chris Lattner
In reply to this post by Holger Schurig-2
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/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: c const

Christopher Lamb

On Aug 16, 2007, at 9:09 AM, Chris Lattner wrote:

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.

If you use a const * __restrict pointer then you should get the benefit of this as the alias analysis will assume that the pointed to object is neither aliased nor written.

--
Christopher Lamb




_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: c const

Duncan Sands
Hi Christopher,

On Friday 17 August 2007 19:42:31 Christopher Lamb wrote:
> On Aug 16, 2007, at 9:09 AM, Chris Lattner wrote:
> > 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.
>
> If you use a const * __restrict pointer then you should get the  
> benefit of this as the alias analysis will assume that the pointed to  
> object is neither aliased nor written.

can you please explain more about what restrict means: it may help
in improving code quality for Ada.  In Ada you have runtime constants
that are really constant, for example array bounds.  The bounds are
passed around by pointer, which causes LLVM to think they may be
aliased and changed by function calls (which is impossible).  This
results on rotten code since (for example) the array length and
bounds checks are recalculated again and again when one calculation
would do.  [The front-end outputs a bound check for every array access,
expecting the optimizers to remove redundant checks, which LLVM often
does not do].  If I could teach LLVM that array bounds are really constant
that would presumably solve the problem.

Thanks,

Duncan.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: c const

Gordon Henriksen-3
On 2007-08-19, at 15:41, Duncan Sands wrote:

can you please explain more about what restrict means: it may help in improving code quality for Ada.  In Ada you have runtime constants that are really constant, for example array bounds.  The bounds are passed around by pointer, which causes LLVM to think they may be aliased and changed by function calls (which is impossible).  This results on rotten code since (for example) the array length and bounds checks are recalculated again and again when one calculation would do.  [The front-end outputs a bound check for every array access, expecting the optimizers to remove redundant checks, which LLVM often does not do].  If I could teach LLVM that array bounds are really constant that would presumably solve the problem.

Here's a thread about it:


I don't think anything has been implemented.

— Gordon


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: c const

Christopher Lamb

On Aug 19, 2007, at 1:15 PM, Gordon Henriksen wrote:

On 2007-08-19, at 15:41, Duncan Sands wrote:

can you please explain more about what restrict means: it may help in improving code quality for Ada.  In Ada you have runtime constants that are really constant, for example array bounds.  The bounds are passed around by pointer, which causes LLVM to think they may be aliased and changed by function calls (which is impossible).  This results on rotten code since (for example) the array length and bounds checks are recalculated again and again when one calculation would do.  [The front-end outputs a bound check for every array access, expecting the optimizers to remove redundant checks, which LLVM often does not do].  If I could teach LLVM that array bounds are really constant that would presumably solve the problem.

The benefits of a const * __restrict come from two different places. The const part is essentially enforced by the front-end and the restrict part is used to inform the alias analysis (it becomes a noalias parameter attribute). The noalias parameter attribute may be of use to you eventually, but full noalias implementation isn't yet complete. Specifically the case where a function with noalias parameter attributes is inlined does not currently preserve the noalias information.

Here's a thread about it:


You should also take a look at PR 1373, as that is where progress is being tracked. http://llvm.org/bugs/show_bug.cgi?id=1373

I don't think anything has been implemented.

Per the discussion and PR there has been work done to implement the 'noalias' parameter attribute in LLVM, and currently BasicAA will use this attribute to inform alias queries that are made. There has also been work to map __restrict C/C++ pointer and reference parameters onto the noalias parameter attribute. There is still much work to be done to fully implement noalias in LLVM, notably the intrinsic and updates to tolerate/use it, as well as to fully support all uses of the __restrict qualifier in the C/C++ front end.

--
Christopher Lamb




_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
12