This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Confused about rtl generation


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]