similar to: [LLVMdev] IntrinsicLowering and several related problems

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, This is more of an RFC than for committing (hence the post to llvmdev) but I'd like to have some opinions on these improvements to IntrinsicLowering before I go ahead and implement the rest of the intrinsics. My main motivation for the single-thread lowering is to be able to run code that uses these intrinsics in the KLEE symbolic execution engine but I imagine it could have other uses

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

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 result = get_ptr(a)(4); ------------- In LLVM Code -------------- %4 = call float (i32)* (float

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

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, > %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.

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

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

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, > 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.

Hello Duncan, There is a discussion with Chris Lattner: http://old.nabble.com/Eliminating-the-'void'-type-td33726468.html In the discussion, Chris Lattner suggest Type::getVoidTy() should still exist and return {} for API continuity. If VoidTy and isVoidTy() go away, how do deal with the isVoidTy() function call in LLVM source tree? Another issue is: What should ReturnInst constructor

Hi Peter, > My main motivation for the single-thread lowering is to be able to run > code that uses these intrinsics in the KLEE symbolic execution engine > but I imagine it could have other uses such as a whole-program LTO > that lowers atomic operations to more efficient non-atomic operations > when it is known to be safe to do so. instead, how about writing an LLVM IR pass that