similar to: [LLVMdev] PHI instruction -- How to avoid and how to remove?

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

"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

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)

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

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

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

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

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

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

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

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

Hi, I work on a pass that requires as input LLVM code without any phi nodes. For this, I use the reg2mem pass which produces suitable code, the pass runs correctly, but I obtain a significant performance decrease. I expect that this is because there are more reads / writes to memory after running the reg2mem pass. How can I optimize the code, without inserting any phi nodes? Or is there a

Somewhere during optimization PHI nodes on pointer types (including alloca instructions) are being introduced, and they persist through the scalar replacement of aggregates pass and others. I can't seem to find a combination of passes or transformations to get rid of them. Has anyone had this problem before, and know a transformation to eliminate it? My optimization passes rely on

So my best bet is to try and work in reg2mem mode and then go back to mem2reg? I'm curious, it seems though when you split a block that the phis get updated, right? On Thu, Feb 2, 2012 at 5:05 PM, Eric Christopher <echristo at apple.com> wrote: > Not that I'm aware of. > > -eric > > On Feb 2, 2012, at 3:47 PM, Ryan Taylor wrote: > > So essentially I'm