similar to: [LLVMdev] Why function pointer is different from other data type?

Hao Shen wrote: > Dear all, > > I compiled c program with llvm and found something strange with > function pointer as following small example . > > ------------- In C Code -------------- > float a (int value) { > return value + 1; > }; > > typedef float (*funcptr_t) (int); > > funcptr_t get_ptr(funcptr_t p) { > return p; > } > > float

I'm sorry that I should remove the comment. In fact my question is about the "float (i32)* (float (i32)*)*", why we use this kind of return type instead of just "float (i32)*". Thanks a lot. Hao On Mon, Apr 12, 2010 at 5:42 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Hao Shen, > >> %4 = call float (i32)* (float (i32)*)* @get_ptr(float (i32)* @a1)

"float (i32)* (float (i32)*)*" is not a return type. According to the description of the 'call' instruction in LLVM Assembly Language Reference Manual (http://llvm.org/docs/LangRef.html#i_call) this is a signature of the pointer to function value being invoked (which includes the return type). In your case the full signature is printed because get_ptr returns a pointer to

Hi Hao Shen, > %4 = call float (i32)* (float (i32)*)* @get_ptr(float (i32)* @a1) > nounwind ;<float (i32)*> [#uses=1] > ~~~~~~~~~~~~~~~~~~~~ VERY STRANGE RETURN TYPE !!! this is a comment, and only exists to help the human reader. Comments start with a semi-colon (;). You can remove them if you like. Ciao, Duncan.

Most LLVM IR instructions have a result field, according to the Language Reference. I want to know, for all LLVM Instructions, is there an easy and consistent way to know if the current Inst has a result field? And if yes, what is the best way to obtain it? E.g.: <result> = add<ty> <op1>,<op2> /; yields {ty}:result / All ADD instruction will have a

Hi Chuck, > Most LLVM IR instructions have a result field, according to the Language Reference. > > I want to know, for all LLVM Instructions, is there an easy and consistent way > to know if the current Inst has a result field? > And if yes, what is the best way to obtain it? the instruction is the result! So everywhere you though you needed to use Instruction->getResult(),

I’m not entirely opposed to solution #3. As I said, my concern is that there are cases it would miss. For instance, if I had some code like this: char *get_ptr(char *base, intptr_t offset) { return base + offset; } char *convert_to_ptr(intptr_t ptr_val) { return get_ptr((char*)0, ptr_val); } There the idiom would only appear after inlining, so the front end couldn’t handle it. The

On Mon, May 10, 2010 at 7:19 PM, John Criswell <criswell at uiuc.edu> wrote: > SHEN Hao wrote: >> Thanks a lot for your answer. >> As what you said, I can not have any options to avoid generating this kind >> of intrinsic for byte code. Is it possible to modify gcc and ask it take >> all memset liked functions as a general function call? I know this solution

Thanks a lot for your answer. As what you said, I can not have any options to avoid generating this kind of intrinsic for byte code. Is it possible to modify gcc and ask it take all memset liked functions as a general function call? I know this solution is less performance efficient, but I would like to have it for my llvm assembly level modification works. But anyway, thanks for you help. Hao

On Mon, Jun 7, 2010 at 5:49 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Hao Shen, > >> Is there anyone who knows well i80 data type? Is there any >> corresponding data type >> for X86 processor? uint80_t or int80_t for gcc? > > no, there is no native processor support for i80. GCC does not have > a direct equivalent to i80. However if you declare a

Dear all, Is there anyone knows how to configure the llvm-gcc to avoid generate the PHI instruction in the bytecode? If not possible, can you explain me what's the real idea of the PHI instruction and how to replace this instruction with a group of other instructions? Thanks a lot. -- Hao Shen

Dear all, Is there anyone who knows well i80 data type? Is there any corresponding data type for X86 processor? uint80_t or int80_t for gcc? PS. I found that the LLVM website is down! -- Hao Shen

Dear all, I'm using IntrinsicLowering class to remove all intrinsics in LLVM byte-code. Unfortunately, I meet several problems: 1. Why I can not get the type of CallInst *CI? !CI->getType()->isVoidTy() is not working and how to solve it? This type information has some impacts with intrinsics such as flt_rounds. 2. Why Intrinsic::vastart and Intrinsic::powi are excluded from

Hi, all, I am using llvm-gcc --emit-llvm to generate byte code. With llvm readable ll format, I found some standard C library function such as llvm.memset. In fact, I'm trying to compile newlibc with llvm, I do not need this kind of llvm functions. How can I remove them during the compilation? Best regards, -- Hao Shen

SHEN Hao wrote: > Thanks a lot for your answer. > As what you said, I can not have any options to avoid generating this kind > of intrinsic for byte code. Is it possible to modify gcc and ask it take > all memset liked functions as a general function call? I know this solution > is less performance efficient, but I would like to have it for my llvm > assembly level modification

Hi Hao Shen, > I am using llvm-gcc --emit-llvm to generate byte code. With llvm > readable ll format, I found some standard C library function such as > llvm.memset. this is not a C library function, it is an LLVM intrinsic. An intrinsic is analogous to a builtin in gcc. An intrinsic may be expanded out into a code sequence by the compiler, or may get turned into a library call (which

On 06/04/2010 01:18 PM, SHEN Hao wrote: > Dear all, > > Is there anyone knows how to configure the llvm-gcc to avoid generate > the PHI instruction in the bytecode? Use opt -reg2mem (however it'll also replace all virtual registers). > If not possible, can you explain me what's the real idea of the PHI > instruction and how to replace this instruction with a group of

Hi Hao Shen, > 1. Why I can not get the type of CallInst *CI? > !CI->getType()->isVoidTy() is not working and how to solve it? what does "not working" mean? It should work. > 2. Why Intrinsic::vastart and Intrinsic::powi are excluded from > IntrinsicLowering function? > There are no way to lower them at the byte-code level? For vastart, it probably isn't

Hi Hao Shen, > Is there anyone who knows well i80 data type? Is there any > corresponding data type > for X86 processor? uint80_t or int80_t for gcc? no, there is no native processor support for i80. GCC does not have a direct equivalent to i80. However if you declare a 80-bit wide C bitfield, then arithmetic on it is done in 80 bits. For example, here gcc should perform i3

Hi Hao Shen, > OK, thanks a lot. I can understand how i80 works. > But why i80 appears in my byte-code? How to remove it > by using some passes? it may be created by the sroa (scalarrepl) pass which sometimes introduces such registers when 10 bytes are being loaded from memory. Why do you want to remove it? Ciao, Duncan.