MELT plugin 0.9.2 for GCC 4.6 (& future 4.7) available
Hello All,
It is my pleasure to announce the MELT plugin 0.9.2 release candidate 2
December 08th, 2011: Release of MELT plugin 0.9.2 for gcc-4.6 (& future gcc-4.7)
dedicated to the memory of John McCarthy
http://en.wikipedia.org/wiki/John_McCarthy_(computer_scientist)
MELT is a high-level domain specific language to extend GCC (GPLv3 licensed,
FSF oopyrighted)
You can download the gzipped source tar archive, from
http://gcc-melt.org/melt-0.9.2-plugin-for-gcc-4.6.tgz of 4186599 bytes
bytes and md5sum914c8e2bde0388ec15013c8ff4b35e23 (december 07th 2011). It
is extracted from MELT branch svn revision 182101. The version number 0.9.2
of the MELT plugin is unrelated to the version of the GCC compiler (4.6 or
4.7) for which it is supposed to work. Bug reports and patches are welcome
(to the gcc-m...@googlegroups.com list).
[[I've made a few minor bug-fixes in the Makefile & the runtime w.r.t. to
candidates 0.9.2-rc1 & 0.9.2-rc2]]
### NEWS for MELT 0.9.2
Several bug fixes.
New features:
cloning of values
=
The CLONE_WITH_DISCRIMINANT primitive -whose implementation is mostly
generated- enables creating new values, nearly clones of old
ones. Usage is
(clone_with_discriminant )
If the new discriminant is compatible with the old value's
discriminant, a new value is allocated. If it is not compatible nor
not a discriminant, the old value is returned. In particular, it is
possible to use
(clone_with_discriminant (lambda ) discr_debug_closure)
to make a debugging closure.
debugging closures
==
The DEBUG macro (and the underlying MELT_DEBUG_FUN which you should
not use directly) handles closure with the DISCR_DEBUG_CLOSURE
discriminant specially (somehow like C++ manipulators for
ostream-s). If an argument is a debugging closure of exactly the
DISCR_DEBUG_CLOSURE discriminant, the next argument is displayed using
that debugging closure.
Walking SSA use-def chains
==
The primitives WALK_USE_DEF_CHAIN_BREADTH_FIRST &
WALK_USE_DEF_CHAIN_DEPTH_FIRST enables to walk thru the use-def chains
in SSA passes.
More support notably for Gimple & Tree
==
Several functions, cmatchers, primitives have been defined, notably
GIMPLE_ASSIGN_TO, WALK_USE_DEF_CHAIN_BREADTH_FIRST &
WALK_USE_DEF_CHAIN_DEPTH_FIRST, EACHGIMPLEPHI_IN_BASICBLOCK
New MELT hooks for PLUGIN_FINISH_TYPE & PLUGIN_FINISH_DECL
==
MELT functions can be registered using
REGISTER_FINISH_TYPE_HOOK_FIRST, REGISTER_FINISH_TYPE_HOOK_LAST,
REGISTER_FINISH_DECL_HOOK_FIRST, REGISTER_FINISH_DECL_HOOK_LAST. The
argument is a boxed tree value. The PLUGIN_FINISH_DECL don't exist in
GCC 4.6 (only in GCC 4.7 and later).
New MELT hooks for other events
===
MELT functions can be register for PLUGIN_ALL_PASSES_START,
PLUGIN_ALL_PASSES_END, PLUGIN_ALL_IPA_PASSES_START,
PLUGIN_ALL_IPA_PASSES_END, PLUGIN_EARLY_GIMPLE_PASSES_START,
PLUGIN_EARLY_GIMPLE_PASSES_END event using
REGISTER_ALL_IPA_PASSES_END_HOOK_FIRST
REGISTER_ALL_IPA_PASSES_END_HOOK_LAST
REGISTER_ALL_IPA_PASSES_START_HOOK_FIRST
REGISTER_ALL_IPA_PASSES_START_HOOK_LAST
REGISTER_ALL_PASSES_END_HOOK_FIRST
REGISTER_ALL_PASSES_END_HOOK_LAST
REGISTER_ALL_PASSES_START_HOOK_FIRST
REGISTER_ALL_PASSES_START_HOOK_LAST
REGISTER_EARLY_GIMPLE_PASSES_END_HOOK_FIRST
REGISTER_EARLY_GIMPLE_PASSES_END_HOOK_LAST
REGISTER_EARLY_GIMPLE_PASSES_START_HOOK_FIRST
REGISTER_EARLY_GIMPLE_PASSES_START_HOOK_LAST
More runtime code generated
===
More runtime code is generated internally.
Bug reports and suggestions are always welcome on gcc-m...@googlegroups.com
or on gcc@gcc.gnu.org. Patches are welcome on gcc-m...@googlegroups.com and
on gcc-patc...@gcc.gnu.org with [MELT] tag.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
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 return value of the function fread. So I suppose that I need a cast here to cast from the return type of fread -> type_of (lhs). But I've no idea how could I achieve this? Any suggestions? Thanks, Feng
Bug in Tree to RTL expansion?
Hi, I experienced a code generation bug with 4.5 (yes, our port is still stuck at 4.5.4). Since the concerned code is full of our target-specific code, it is not easy to demonstrate the error with x86 or ARM. Here is what happens in expanding process. The following is a piece of optimized tree code to be expanded to RTL. # ptr_h2_493 = PHI ... D.13598_218 = MEM[base: ptr_h2_493, offset: 8]; D.13599_219 = (long int) D.13598_218; ... ptr_h2_310 = ptr_h2_493 + 16; ... D.13634_331 = D.13599_219 * D.13538_179; cor3_332 = D.13635_339 + D.13634_331; ... When expanding to RTL, the coalescing algorithm will coalesce ptr_h2_310 & ptr_h2_493 to one register: ;; ptr_h2_310 = ptr_h2_493 + 16; (insn 364 363 0 (set (reg/v/f:SI 282 [ ptr_h2 ]) (plus:SI (reg/v/f:SI 282 [ ptr_h2 ]) (const_int 16 [0x10]))) -1 (nil)) GCC 4.5 (fp_gcc 2.3.x) doesn't expand statements one-by-one as GCC 4.4 (fp_gcc 2.2.x) does. So when GCC expands the following statement, cor3_332 = D.13635_339 + D.13634_331; it then in turn expands each operand by going back to expand previous relevant statements. D.13598_218 = MEM[base: ptr_h2_493, offset: 8]; D.13599_219 = (long int) D.13598_218; ... D.13634_331 = D.13599_219 * D.13538_179; The problem is that compiler doesn't take account into fact that ptr_h2_493|ptr_h2_310 has been modified. Still expand the above statement as it is. (insn 380 379 381 (set (reg:HI 558) (mem:HI (plus:SI (reg/v/f:SI 282 [ ptr_h2 ]) (const_int 8 [0x8])) [0 S2 A8])) -1 (nil)) ... (insn 382 381 383 (set (reg:SI 557) (mult:SI (sign_extend:SI (reg:HI 558)) (sign_extend:SI (reg:HI 559 -1 (nil)) This seems to me quite a basic issue. I cannot believe testsuites and other applications do not expose more errors. What I am not sure is whether the coalescing algorithm or the expanding procedure is wrong here. If ptr_h2_493 and ptr_h2_310 are not coalesced to use the same register, it should be correctly compiled. Or expanding procedure checks data flow, it should be also OK. Which one should I I look at? Or is this a known issue and fixed in 4.6/4.7? Thanks, Bingfeng Mei
Re: Bug in Tree to RTL expansion?
On Thu, Dec 8, 2011 at 12:34 PM, Bingfeng Mei wrote: > Hi, > I experienced a code generation bug with 4.5 (yes, our > port is still stuck at 4.5.4). Since the concerned code > is full of our target-specific code, it is not easy > to demonstrate the error with x86 or ARM. > > Here is what happens in expanding process. The following is a > piece of optimized tree code to be expanded to RTL. > > # ptr_h2_493 = PHI > ... > D.13598_218 = MEM[base: ptr_h2_493, offset: 8]; > D.13599_219 = (long int) D.13598_218; > ... > ptr_h2_310 = ptr_h2_493 + 16; > ... > D.13634_331 = D.13599_219 * D.13538_179; > cor3_332 = D.13635_339 + D.13634_331; > ... > > When expanding to RTL, the coalescing algorithm will coalesce > ptr_h2_310 & ptr_h2_493 to one register: > > ;; ptr_h2_310 = ptr_h2_493 + 16; > (insn 364 363 0 (set (reg/v/f:SI 282 [ ptr_h2 ]) > (plus:SI (reg/v/f:SI 282 [ ptr_h2 ]) > (const_int 16 [0x10]))) -1 (nil)) > > GCC 4.5 (fp_gcc 2.3.x) doesn't expand statements one-by-one > as GCC 4.4 (fp_gcc 2.2.x) does. So when GCC expands the > following statement, > > cor3_332 = D.13635_339 + D.13634_331; > > it then in turn expands each operand by going back to > expand previous relevant statements. > > D.13598_218 = MEM[base: ptr_h2_493, offset: 8]; > D.13599_219 = (long int) D.13598_218; > ... > D.13634_331 = D.13599_219 * D.13538_179; > > The problem is that compiler doesn't take account into fact that > ptr_h2_493|ptr_h2_310 has been modified. Still expand the above > statement as it is. > > (insn 380 379 381 (set (reg:HI 558) > (mem:HI (plus:SI (reg/v/f:SI 282 [ ptr_h2 ]) > (const_int 8 [0x8])) [0 S2 A8])) -1 (nil)) > ... > (insn 382 381 383 (set (reg:SI 557) > (mult:SI (sign_extend:SI (reg:HI 558)) > (sign_extend:SI (reg:HI 559 -1 (nil)) > > This seems to me quite a basic issue. I cannot believe testsuites > and other applications do not expose more errors. > > What I am not sure is whether the coalescing algorithm or the expanding > procedure is wrong here. If ptr_h2_493 and ptr_h2_310 are not coalesced > to use the same register, it should be correctly compiled. Or expanding > procedure checks data flow, it should be also OK. Which one should I > I look at? Or is this a known issue and fixed in 4.6/4.7? TER should not happen for D.13598_218 = MEM[base: ptr_h2_493, offset: 8]; because it conflicts with the coalesce. Thus, -fno-tree-ter should fix your issue. You may look at the -fdump-rtl-expand-details dump to learn about the coalescing decisions. I'm not sure we fixed a bug that looks like the above. With 4.5 the 'MEM' is a TARGET_MEM_REF tree. Micha should be most familiar with evolutions in this code. Richard. > Thanks, > Bingfeng Mei >
Re: How could I cast the return type of a function created by gimple_build_call?
Hi, On Thu, Dec 08, 2011 at 10:38:24AM +0100, Feng LI wrote: > 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 return > value > of the function fread. So I suppose that I need a cast here to cast from the > return type of fread -> type_of (lhs). But I've no idea how could I > achieve this? > Any suggestions? You need to store the result into a temporary and then add a VIEW_CONVERT_EXPR gimple assignment statement after the statement to convert to the necessary type. Grep *.c files for 'build.*VIEW_CONVERT_EXPR' and you should be able to find some example to follow in your own code. Martin
Re: How could I cast the return type of a function created by gimple_build_call?
On Thu, Dec 8, 2011 at 1:26 PM, Martin Jambor wrote: > Hi, > > On Thu, Dec 08, 2011 at 10:38:24AM +0100, Feng LI wrote: >> 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 return >> value >> of the function fread. So I suppose that I need a cast here to cast from the >> return type of fread -> type_of (lhs). But I've no idea how could I >> achieve this? >> Any suggestions? > > You need to store the result into a temporary and then add a > VIEW_CONVERT_EXPR gimple assignment statement after the statement to > convert to the necessary type. Grep *.c files for > 'build.*VIEW_CONVERT_EXPR' and you should be able to find some example > to follow in your own code. A traditional cast is a NOP_EXPR. If you really need a VIEW_CONVERT_EXPR then this is more like a *(T' *)&t operation. Richard. > Martin
RE: Bug in Tree to RTL expansion?
Richard, Thanks. -fno-tree-ter does work around the problem. I did look at the info about coalescing, which doesn't give much info. I think I have to take a closer look at TER and coalescing algorithm. Regards, Bingfeng > -Original Message- > From: Richard Guenther [mailto:richard.guent...@gmail.com] > Sent: 08 December 2011 12:10 > To: Bingfeng Mei > Cc: gcc@gcc.gnu.org; Michael Matz > Subject: Re: Bug in Tree to RTL expansion? > > On Thu, Dec 8, 2011 at 12:34 PM, Bingfeng Mei wrote: > > Hi, > > I experienced a code generation bug with 4.5 (yes, our > > port is still stuck at 4.5.4). Since the concerned code > > is full of our target-specific code, it is not easy > > to demonstrate the error with x86 or ARM. > > > > Here is what happens in expanding process. The following is a > > piece of optimized tree code to be expanded to RTL. > > > > # ptr_h2_493 = PHI > > ... > > D.13598_218 = MEM[base: ptr_h2_493, offset: 8]; > > D.13599_219 = (long int) D.13598_218; > > ... > > ptr_h2_310 = ptr_h2_493 + 16; > > ... > > D.13634_331 = D.13599_219 * D.13538_179; > > cor3_332 = D.13635_339 + D.13634_331; > > ... > > > > When expanding to RTL, the coalescing algorithm will coalesce > > ptr_h2_310 & ptr_h2_493 to one register: > > > > ;; ptr_h2_310 = ptr_h2_493 + 16; > > (insn 364 363 0 (set (reg/v/f:SI 282 [ ptr_h2 ]) > > (plus:SI (reg/v/f:SI 282 [ ptr_h2 ]) > > (const_int 16 [0x10]))) -1 (nil)) > > > > GCC 4.5 (fp_gcc 2.3.x) doesn't expand statements one-by-one > > as GCC 4.4 (fp_gcc 2.2.x) does. So when GCC expands the > > following statement, > > > > cor3_332 = D.13635_339 + D.13634_331; > > > > it then in turn expands each operand by going back to > > expand previous relevant statements. > > > > D.13598_218 = MEM[base: ptr_h2_493, offset: 8]; > > D.13599_219 = (long int) D.13598_218; > > ... > > D.13634_331 = D.13599_219 * D.13538_179; > > > > The problem is that compiler doesn't take account into fact that > > ptr_h2_493|ptr_h2_310 has been modified. Still expand the above > > statement as it is. > > > > (insn 380 379 381 (set (reg:HI 558) > > (mem:HI (plus:SI (reg/v/f:SI 282 [ ptr_h2 ]) > > (const_int 8 [0x8])) [0 S2 A8])) -1 (nil)) > > ... > > (insn 382 381 383 (set (reg:SI 557) > > (mult:SI (sign_extend:SI (reg:HI 558)) > > (sign_extend:SI (reg:HI 559 -1 (nil)) > > > > This seems to me quite a basic issue. I cannot believe testsuites > > and other applications do not expose more errors. > > > > What I am not sure is whether the coalescing algorithm or the > expanding > > procedure is wrong here. If ptr_h2_493 and ptr_h2_310 are not > coalesced > > to use the same register, it should be correctly compiled. Or > expanding > > procedure checks data flow, it should be also OK. Which one should I > > I look at? Or is this a known issue and fixed in 4.6/4.7? > > TER should not happen for D.13598_218 = MEM[base: ptr_h2_493, offset: > 8]; because it conflicts with the coalesce. Thus, -fno-tree-ter > should > fix your issue. You may look at the -fdump-rtl-expand-details dump > to learn about the coalescing decisions. > > I'm not sure we fixed a bug that looks like the above. With 4.5 > the 'MEM' is a TARGET_MEM_REF tree. > > Micha should be most familiar with evolutions in this code. > > Richard. > > > Thanks, > > Bingfeng Mei > >
Re: RFC - GCC Architectural Goals
On 12/07/11 22:20, 陳韋任 wrote: However, it is true that some patches are not in that category. In general, we prefer to keep patch traffic in a single place (gcc-patches@), but we use message tagging extensively. How about '[trivial]'? If reviwer can pick up trivial patches easily by this way, I have no objection. :) In general, this is how we operate. So, all I can say here is "send your patches". We do have a set of very active reviewers, but I do not think we have good metrics on patch review timeliness. Diego.
Re: Bug in Tree to RTL expansion?
Hi, On Thu, 8 Dec 2011, Richard Guenther wrote: > > What I am not sure is whether the coalescing algorithm or the > > expanding procedure is wrong here. The forwarding of _218 is wrong. TER shouldn't have marked it as being able to forward (check the expand-detailed dump for the "Replacing Expressions" section). Obviously it does think it can forward it, so something is wrong in tree-ssa-ter.c. If you can't come up with a testcase that fails with some available cross compiler (though I wonder why, the tree-ssa parts of the compiler are not that target dependend, so maybe you can show similar forwarding with an adjusted testcase for something publically available) you have to debug it yourself (I'm right now not aware of any known bug in 4.5 regarding this particular situation). There should be a call to kill_expr on the statement ptr_h2_310 = ptr_h2_493 + 16; which should have killed the expression MEM[ptr_h2_493] (and hence _218) from the available expressions. Ciao, Michael.
Re: Bug in Tree to RTL expansion?
On Thu, Dec 8, 2011 at 2:49 PM, Michael Matz wrote: > Hi, > > On Thu, 8 Dec 2011, Richard Guenther wrote: > >> > What I am not sure is whether the coalescing algorithm or the >> > expanding procedure is wrong here. > > The forwarding of _218 is wrong. TER shouldn't have marked it as being > able to forward (check the expand-detailed dump for the "Replacing > Expressions" section). Obviously it does think it can forward it, so > something is wrong in tree-ssa-ter.c. > > If you can't come up with a testcase that fails with some available cross > compiler (though I wonder why, the tree-ssa parts of the compiler are not > that target dependend, so maybe you can show similar forwarding with an > adjusted testcase for something publically available) you have to debug it > yourself (I'm right now not aware of any known bug in 4.5 regarding this > particular situation). > > There should be a call to kill_expr on the statement > ptr_h2_310 = ptr_h2_493 + 16; > which should have killed the expression MEM[ptr_h2_493] (and hence _218) > from the available expressions. Which reminds me of 2011-09-09 Richard Guenther * tree-ssa-operands.c (swap_tree_operands): Always adjust existing operand positions. can you try backporting that? Richard. > > Ciao, > Michael.
Re: volatile correctness: combine vs. target.md
Ian Lance Taylor wrote: > Georg-Johann Lay: >> >> What about that predicate? >> >> (define_predicate "low_io_mem" >>(and (match_code "mem") >> (match_test "low_io_address_operand (XEXP (op, 0))"))) >> >> Guess it operates the same because the drag-volatile-over-volatile >> happens not in recog(_for_combine) but already when combine >> synthesizes new patterns. Jepp, I tried that. Just as I expected, it is no cure. >> As combine juggles with data flow, it must >> not exchange volatiles. That's all. The backend will know if it's ok >> to place a specific operand into a specific insn or not. >> >> And skipping optimizations like these altogether because they are >> uncomfortable to handle is the wrong direction, IMHO. > > OK, what is your proposed patch to combine? Maybe it is easy to make it > do what you want. I haven't looked. > > Ian No, I have no patch. But I had a closer look at combine.c: In try_combine, just after the "Trying..." dump output, we have: i0 = 0 i1 = 0 i2 = (set (reg/v:QI 43 [ status ]) (mem/v:QI (const_int 43 [0x2b]))) i3 = (set (pc) (if_then_else (eq (zero_extract:QI (reg/v:QI 43 [ status ]) (const_int 1) (const_int 4)) (const_int 0)) (label_ref:HI 16) (pc))) where to potential insertion is i2 into i3. These insns are fed into can_combine_p with src = (mem/v:QI (const_int 43)) dest = (reg/v:QI 43) and then there is this part of an if-clause: /* Make sure that the value that is to be substituted for the register does not use any registers whose values alter in between. However, If the insns are adjacent, a use can't cross a set even though we think it might (this can happen for a sequence of insns each setting the same destination; last_set of that register might point to a NOTE). If INSN has a REG_EQUIV note, the register is always equivalent to the memory so the substitution is valid even if there are intervening stores. Also, don't move a volatile asm or UNSPEC_VOLATILE across any other insns. */ || (! all_adjacent && (((!MEM_P (src) || ! find_reg_note (insn, REG_EQUIV, src)) && use_crosses_set_p (src, DF_INSN_LUID (insn))) || (GET_CODE (src) == ASM_OPERANDS && MEM_VOLATILE_P (src)) || GET_CODE (src) == UNSPEC_VOLATILE)) In addition to these tests, the following must be disallowed: If src contains volatile memory, then disallow moving it across: * volatile memory * unspec_volatile * asm volatile As far as I can see, use_crosses_set_p (src,...) returns 0 (false) which is incorrect. So either use_crosses_set_p is incorrect or it relies on incorrect data from data flow analysis or from wherever. Johann
Re: MELT plugin 0.9.2.b for GCC 4.6 (& future 4.7) available
Hello All,
Sorry for the quasi-repeated message (I've send a wrong one just at the start
of a fire
alarm exercise...)
(I had to correct a last-minute bug in the MELT 0.9.2 plugin, so I am releasing
the
MELT plugin 0.9.2.b for GCC 4.6 & future 4.7)
It is my pleasure to announce the MELT plugin 0.9.2.b release
December 08th, 2011: Release of MELT plugin 0.9.2.b for gcc-4.6 (& future
gcc-4.7)
dedicated to the memory of John McCarthy
http://en.wikipedia.org/wiki/John_McCarthy_(computer_scientist)
MELT is a high-level domain specific language to extend GCC (GPLv3 licensed, FSF
oopyrighted)
You can download the gzipped source tar archive, from
http://gcc-melt.org/melt-0.9.2.b-plugin-for-gcc-4.6.tgz of 4198307 bytes
bytes and md5sum 980c1a4324d29c6ad2ccdde8254d266a (december 08th 2011). It
is extracted from MELT branch svn revision 182130. The version number 0.9.2.b
of the MELT plugin is unrelated to the version of the GCC compiler (4.6 or
4.7) for which it is supposed to work. Bug reports and patches are welcome
(to the gcc-m...@googlegroups.com list).
### NEWS for MELT 0.9.2.b
Several bug fixes.
New features:
cloning of values
=
The CLONE_WITH_DISCRIMINANT primitive -whose implementation is mostly
generated- enables creating new values, nearly clones of old
ones. Usage is
(clone_with_discriminant )
If the new discriminant is compatible with the old value's
discriminant, a new value is allocated. If it is not compatible nor
not a discriminant, the old value is returned. In particular, it is
possible to use
(clone_with_discriminant (lambda ) discr_debug_closure)
to make a debugging closure.
debugging closures
==
The DEBUG macro (and the underlying MELT_DEBUG_FUN which you should
not use directly) handles closure with the DISCR_DEBUG_CLOSURE
discriminant specially (somehow like C++ manipulators for
ostream-s). If an argument is a debugging closure of exactly the
DISCR_DEBUG_CLOSURE discriminant, the next argument is displayed using
that debugging closure.
Walking SSA use-def chains
==
The primitives WALK_USE_DEF_CHAIN_BREADTH_FIRST &
WALK_USE_DEF_CHAIN_DEPTH_FIRST enables to walk thru the use-def chains
in SSA passes.
More support notably for Gimple & Tree
==
Several functions, cmatchers, primitives have been defined, notably
GIMPLE_ASSIGN_TO, WALK_USE_DEF_CHAIN_BREADTH_FIRST &
WALK_USE_DEF_CHAIN_DEPTH_FIRST, EACHGIMPLEPHI_IN_BASICBLOCK
New MELT hooks for PLUGIN_FINISH_TYPE & PLUGIN_FINISH_DECL
==
MELT functions can be registered using
REGISTER_FINISH_TYPE_HOOK_FIRST, REGISTER_FINISH_TYPE_HOOK_LAST,
REGISTER_FINISH_DECL_HOOK_FIRST, REGISTER_FINISH_DECL_HOOK_LAST. The
argument is a boxed tree value. The PLUGIN_FINISH_DECL don't exist in
GCC 4.6 (only in GCC 4.7 and later).
New MELT hooks for other events
===
MELT functions can be register for PLUGIN_ALL_PASSES_START,
PLUGIN_ALL_PASSES_END, PLUGIN_ALL_IPA_PASSES_START,
PLUGIN_ALL_IPA_PASSES_END, PLUGIN_EARLY_GIMPLE_PASSES_START,
PLUGIN_EARLY_GIMPLE_PASSES_END event using
REGISTER_ALL_IPA_PASSES_END_HOOK_FIRST
REGISTER_ALL_IPA_PASSES_END_HOOK_LAST
REGISTER_ALL_IPA_PASSES_START_HOOK_FIRST
REGISTER_ALL_IPA_PASSES_START_HOOK_LAST
REGISTER_ALL_PASSES_END_HOOK_FIRST
REGISTER_ALL_PASSES_END_HOOK_LAST
REGISTER_ALL_PASSES_START_HOOK_FIRST
REGISTER_ALL_PASSES_START_HOOK_LAST
REGISTER_EARLY_GIMPLE_PASSES_END_HOOK_FIRST
REGISTER_EARLY_GIMPLE_PASSES_END_HOOK_LAST
REGISTER_EARLY_GIMPLE_PASSES_START_HOOK_FIRST
REGISTER_EARLY_GIMPLE_PASSES_START_HOOK_LAST
More runtime code generated
===
More runtime code is generated internally.
Additional translating MELT modes
=
The translatetomodule mode produces all three flavors
(.quicklybuilt.so, .debugnoline.so, .optimized.so) of modules
The translateoptimized mode produces .optimized.so flavor of modules
Bug reports and suggestions are always welcome on gcc-m...@googlegroups.com
or on gcc@gcc.gnu.org. Patches are welcome on gcc-m...@googlegroups.com and
on gcc-patc...@gcc.gnu.org with [MELT] tag.
There will be a tutorial about GCC MELT at Hipeac 2012 in Paris (end of January
2012)
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
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 with* the middle end automatically generated functions. 1. In the middle end where l generate the builtin functions using the following way: tree decl = build_decl (UNKNOWN_LOCATION, FUNC_DECL, get_identifier (name), type); TREE_PUBLIC (decl) = 1; DECL_EXTERNAL (decl) = 1; DECL_BUILT_IN_CLASS (decl) = BUILT_IN_MD; Here the BUILT_IN_MD is set to make sure the backend could catch and handle for this situation. 2. In the backend, the builtin functions are defined using: def_builtin (OPTION_MASK_ISA_FOO, "__builtin_ia32_foo", VOID_FTYPE_VOID, IX86_BUILTIN_FOO); And it'll works with the MD file to generate the ASM. I'm not sure if I need some extra work to glue these together, but I think since it works with a hand written file, it should work with the auto-generated builtin functions in the middle end. Confused... Any suggestions will be appreciated. Thanks, Feng
gcc-4.5-20111208 is now available
Snapshot gcc-4.5-20111208 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20111208/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 182142 You'll find: gcc-4.5-20111208.tar.bz2 Complete GCC MD5=a717447f8aa99a1ff1eab69dd63100a8 SHA1=99ba5c09479b5a0bf81692a06d5521de5e2a1359 Diffs from 4.5-20111201 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: middle end generated builtin functions passing to backend problem
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. 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 with* the middle end automatically generated functions. have you looked into ix86_builtin_reciprocal and where it gets used in tree-ssa-math-opts.c ? I think you need a target hook which returns the decl and that decl is the same decl you created in the target. Thanks, Andrew Pinski
