Using intrinsic functions to extend the isa

Hi, I'm currently try to add intrinsic functions to extend the x86 instruction set. Encountered a problem when the intrinsic function's return value is void, where the asm will not generate in this case. the intrinsic function looks like: extern void __attribute__((__gnu_inline__, __always_inlin

Re: Using intrinsic functions to extend the isa

Hi Ian, Thanks for your comments. On Wed, Apr 13, 2011 at 5:02 PM, Ian Lance Taylor wrote: > Feng LI writes: > >> I'm currently try to add intrinsic functions to extend the x86 instruction >> set. Encountered a problem when the intrinsic function's return value &g

Re: Using intrinsic functions to extend the isa

On Wed, Apr 13, 2011 at 5:32 PM, Ian Lance Taylor wrote: > Feng LI writes: > >> I use unspec_volatile for a function with void arguments and >> void return value for some initialization work. But it didn't generate >> code in this case. I think probably I need to

Re: Using intrinsic functions to extend the isa

On Wed, Apr 13, 2011 at 5:48 PM, Richard Guenther wrote: > On Wed, Apr 13, 2011 at 5:45 PM, Feng LI wrote: >> On Wed, Apr 13, 2011 at 5:32 PM, Ian Lance Taylor wrote: >>> Feng LI writes: >>> >>>> I use unspec_volatile for a function with void argume

SET_DEF invalidate the def-use chain.

Hi, I have the code like: a_2 = 5; g1 b_3 = 6; g2 d_4 = a_2 + b_3;g3 And I'd like to insert "tmp.globe = a_2" just after the definition of a_2 (after g1), so that the code will be: a_2 = 5; g1 tmp.globe

Re: SET_DEF invalidate the def-use chain.

May 18, 2011 at 5:01 PM, Feng LI wrote: >> Hi, >> >> I have the code like: >>  a_2 = 5;                         g1 >>  b_3 = 6;                         g2 >>  d_4 = a_2 + b_3;            g3 >> >> And I'd like to insert "tmp.globe = a

An ICE caused by the ssa names.

Hi, I'm trying to outline a function and move all basic-blocks in the function to different child functions. Only left 1 newly created bb in the original function with newly inserted statements. But I got an ICE when gcc call remove_ssa_form for the original function. I debugged the code, it seem

Re: An ICE caused by the ssa names.

Hi Richard, On Thu, May 19, 2011 at 5:53 PM, Richard Guenther wrote: > On Thu, May 19, 2011 at 5:49 PM, Feng LI wrote: >> Hi, >> >> I'm trying to outline a function and move all basic-blocks in the function >> to different child functions. Only left 1

the interface for cloning function

Hi, Is there an interface provided in GCC to clone the current function? I searched in the source code but failed, just in case I'm going wrong. Thanks, Feng

When is the hardware related register is allocated?

Hi, I'm working on a gcc backend, we need to use the information of the allocated hardware register to generate the code from builtin functions. But at the context in ix86_expand_builtin, where I could get the operands which the registers are pseudo registers (REGNO(op)>FIRST_PSEUDO_REGISTER). Do

Re: When is the hardware related register is allocated?

. I'm doing the split phase after "reload_completed". 2. Store the REG CC before CLC, and restore after CMOVC. Is there some way to do that? Thank you, Feng On Mon, Nov 14, 2011 at 7:59 AM, Ian Lance Taylor wrote: > Feng LI writes: > >> I'm working on a gcc backend,

Re: When is the hardware related register is allocated?

On Wed, Nov 16, 2011 at 12:18 PM, Joern Rennecke wrote: > Quoting Ian Lance Taylor : > >> Offhand I don't know of any way to get the compiler to save CC for you >> around your instruction.  That's a stiff requirement. > > It's easy to do under explicit control of the pattern, using (a) > match_scr

How could I cast the return type of a function created by gimple_build_call?

Hi, I'm building a function with fread = build_decl (LOCATION, FUNCTION_DECL, get_identifier (name), type); and then use it in gimple with gimple gfread = gimple_build_call (fread, 1, offset); gimple_call_set_lhs (fread, lhs); But I need a cast here, since the lhs has a different type than the r

middle end generated builtin functions passing to backend problem

Hi, I'm extending the i386 instructions by using the builtins in the backend. And generate the builtin functions in the middle end. And would like the generated builtin functions will be transformed to ASM code. I tested the backend with a hand writing builtin functions, it *works* well, but *not

Re: middle end generated builtin functions passing to backend problem

Hi Andrew, On Thu, Dec 8, 2011 at 11:48 PM, Andrew Pinski wrote: > On Thu, Dec 8, 2011 at 1:47 PM, Feng LI wrote: >> Hi, >> >> I'm extending the i386 instructions by using the builtins in the backend. >> And generate the builtin functions in the middle end.

target specific builtin expansion (middle end and back end definition inconsistence problem?).

Hi, I generate builtin function directly in the middle end and and expand the builtin function in the x86 backend to certain set of instructions. I've defined x86 builtin functions in the gcc backend like this: { OPTION_MASK_ISA_TSTAR | OPTION_MASK_ISA_64BIT, CODE_FOR_tstar_create, "__builtin_ia

Re: target specific builtin expansion (middle end and back end definition inconsistence problem?).

Hi Ian, 2012/4/22 Ian Lance Taylor : > Feng LI writes: > >> I generate builtin function directly in the middle end and and expand >> the builtin function in the x86 backend to certain set of >> instructions. >> >> I've defined x86 built

Re: target specific builtin expansion (middle end and back end definition inconsistence problem?).

Hi Ian, 2012/4/22 Ian Lance Taylor : > Feng LI writes: > >> Yes, you are right. But how could I reference to a backend defined builtin >> function in the middle end (I need to generate the builtin function in the >> middle end and expand it in x86 backend)? > >

Re: target specific builtin expansion (middle end and back end definition inconsistence problem?).

Hi Ian, 2012/4/23 Ian Lance Taylor : > Feng LI writes: > >> Hi Ian, >> >> 2012/4/22 Ian Lance Taylor : >>> Feng LI writes: >>> >>>> Yes, you are right. But how could I reference to a backend defined builtin >>>> function

unrecognizable insn.

Hi, I'm trying to expand a builtin functions into assembles, with processing a little bit for the operands. Like for the builtin function: tcreate (arg0, arg1, arg2) I'm trying to generate the assemble code (pseudo): TCREATE arg0<<32|arg1, arg2 but I got the following error:

assemble code and disassembled code in-consistency

Hi folks, I have a backend hook (x86_64) for builtin function expansion, so I have this: expand_simple_binop (DImode, ASHIFT, op0, GEN_INT (32),op0,1,OPTAB_DIRECT); to generate op0 = op0<<32 (op0 is the first argument of this builtin function, with type SIZE_T) T