similar to: [LLVMdev] c char translated to i8 signext

Thanks for your response. When I attempt to get the parameter attribute lists for the function and its call sites, the list is NULL. Is there someone else I should be looking to get the parameter attributes? Chris Lattner wrote: > On Wed, 30 Apr 2008, Ryan M. Lefever wrote: >> I have a c function that takes a char as a parameter. When it is >> compiled to bytecode, it gets

It appears that the only thing that has parameter attributes is the function type. However, you can't simply change a function's type without reconstructing the whole function, can you? Also, am I correct that it would not be safe to remove the parameter attribute's from a FunctionType? Ryan M. Lefever wrote: > Thanks for your response. When I attempt to get the parameter

On Wed, 30 Apr 2008, Ryan M. Lefever wrote: > I have a c function that takes a char as a parameter. When it is > compiled to bytecode, it gets translated to i8 signext. Why is signext > getting added to the type? It doesn't get added if the parameter is an > int. Is there a way to alter the parameter in the c code so that it > simply gets translated to an i8, or is there a

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

Consider the following c code: #include <stdlib.h> int main(int argc, char** argv){ if(malloc(sizeof(int)) == NULL){ return 0; } else{ return 1; } } When I compile it with -O3, it produces the following bytecode: define i32 @main(i32 %argc, i8** %argv) { entry: ret i32 1 } Is this an error? It should be possible for malloc to return NULL, if it can not allocate more

> 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

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

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

On May 27, 2008, at 3:33 PM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com > wrote: > Chris, > I see, so in deed the front-end sets the attributes on the declaration > of the called function; which in theory is also available to the > caller > through the CALL node. Right. > Now here is what I think: > I agree that 4 attributes are

Hi Chris, please read below: > In many cases that is true, but for indirect calls (calls through a > function pointer) it isn't. > > > All that is needed is to add some kind of sign attribute to the > > definition of callee function which will be set by the front-end and > > eventually saved in Function class. > > Sure. Adding an attribute is what we need

Hello, For a simple function taking a short and returning a short, clang generates IR with this function signature: define signext i16 @foo(i16 signext %x) Some questions please: 1) For the input parameter and return value, does the target control whether clang uses signext vs something else? If so, how does this target query work? 2) Does the presence of the signext mean it's imperative

Hello,everyone: I want to known how to let clang compile my local array to local variables: I have the code : int main() { int a[3]={1,2,3}; int b=7; int c=8; int d=9; int e=10; int f=11; test(b,c,d,e,f,a); return 0; } I use clang command:clang --target=mipsel -emit-llvm -S a.c -o a.ll The a.ll is: @main.a = private unnamed_addr constant [3 x i32] [i32 1, i32 2, i32 3],

> On Dec 27, 2016, at 11:09 PM, liuyu11 at ict.ac.cn via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello,everyone: > I want to known how to let clang compile my local array to local variables: > I have the code : > int main() > { > int a[3]={1,2,3}; > > int b=7; > int c=8; > int d=9; > int e=10; > int f=11; >

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"

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

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Steve King > Sent: 23 July 2015 01:45 > To: llvmdev at cs.uiuc.edu > Subject: [LLVMdev] signext on function parameters and return. > > Hello, > For a simple function taking a short and returning a short, clang > generates IR with this function

Hi, I found a mysterious behavior of LLVM optimizer. I compiled the following code by clang -emit-llvm -S: #include <stddef.h> static const struct t {char t[4]; char s;} p = {{}, 'a'}; char f() { return ((char*)&p)[offsetof(struct t, s)]; } then I obtained the following LLVM IR: %struct.t = type { [4 x i8], i8 } @p = constant %struct.t { [4 x i8] zeroinitializer, i8 97

On Thu, 1 May 2008, Sandro Magi wrote: >> If LLVM is able to eliminate all users of the malloc assuming the >> malloc succeeded (as in this case), then it is safe to assume the malloc >> returned success. > > I don't see how this could be true in general, without either > knowledge of the malloc implementation, which would be fine, or > presuming knowledge of

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 <sabre at nondot.org> 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. >

I am trying to disassemble some bytecode using llvm-dis: llvm-dis -f -o llvmtest/sliceme2.cbc.ll llvmtest/sliceme2.cbc However, I am getting the following error. llvm-dis: Invalid bytecode signature: 464C457F (Vers=0, Pos=4) How do I go about figuring out what the problem is? llvmtest/sliceme2.cbc is newly compiled using the same version of llvm-gcc as llvm-dis. -- Ryan M. Lefever