similar to: [LLVMdev] i80 data type

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

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

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.

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

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

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

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

The mtx binary requires my tape library to be assigned a sg# driver, but the kernel periodically renumbers the sg devices. Normally, we would write a udev rule to manually assign a persistent name, but it looks like things have changed as I can't seem to get a match on CEntOS7. I'd appreciate any feedback or pointers to help me get my rule working. My two attempts are below. cat

Thanks, I did catch the mistype (after IU posted). Still no match with the typo fixed... :-( Thanks, John H. Nyhuis Desk: (206)-685-8334 jnyhuis at uw.edu Box 359461, 15th floor, 106 On 10/29/2019 4:03 AM, Tony Mountifield wrote: > In article <7025a0a8-1471-530d-dad0-3770e902ca31 at uw.edu>, > John H Nyhuis <jnyhuis at uw.edu> wrote: >> The mtx binary requires my tape

hmmm, I thought := assigned a key just like +=, except := locked it so it could not be changed later. Am I misunderstanding the man page for udev? Thanks, John H. Nyhuis Desk: (206)-685-8334 jnyhuis at uw.edu Box 359461, 15th floor, 106 On 10/29/2019 4:31 PM, Leon Fauster via CentOS wrote: > Am 29.10.19 um 23:41 schrieb John H Nyhuis: >> Thanks, I did catch the mistype (after IU