This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Confused about rtl generation
- From: Jim Wilson <wilson at tuliptree dot org>
- To: Marty Hauff <marty dot hauff at rmit dot edu dot au>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 26 Jun 2003 23:54:50 -0700
- Subject: Re: Confused about rtl generation
- References: <sefc2c76.008@its-mn-inet1.its.rmit.edu.au>
Marty Hauff wrote:
I'm trying to track the named instuction patterns used by the compiler when first building the insn list. I've managed to modify GEN_FCN to track when insns are first created however this method does not work for jumps / calls etc. as they don't seem to use GEN_FCN to create the insn. Ideally I would like to find a centralised point through which all standard instruction patterns are first created. Any thoughts ....?
You have a far too simplistic model of how RTL generation works.
GEN_FCN is merely a convenience. Some places use it, some don't. It is
only used for arithmetic/logical instructions, so no, it isn't going to
help with jumps and calls.
Try looking at make_insn_raw, make_jump_insn_raw, make_call_insn_raw.
All instuctions created will go through here. Not all instructions will
be used though. Some are used to compute info, like instruction costs,
and then thrown away. Some are used to test code generation strategies
and then thrown away because the strategy didn't work. Some are
generated by the optimizer and then throw away.
I have modified print-rtl() to print out the insn id and code before each rtl statement dumped into the rtl dump files (code below). I was hoping that the insn code would identify the name of the standard instruction pattern used to generate the insn. Unfortunately this is not so - all of the insn codes seem to be set to -1 (UNMATCHED) in the initial (.00.rtl) dump file so I can't tell what standard pattern was used to create them. Can anyone help.
There is RTL generation, and RTL pattern matching. Some md file
patterns are used for RTL generation only. Some are used for RTL
pattern matching only. And some are used for both.
The INSN_CODE indicates which pattern an insn matches, which may not be
the same pattern that generated. insn matching isn't done unless we
need to do it. For instance, if the optimizer modifies an instruction,
then we need to do a pattern match to see if it is still valid. It
isn't until reload that you can be sure that every instruction has a
valid INSN_CODE. You could always try calling recog() yourself to set
the INSN_CODE field.
Jim