Confused about rtl generation

[Marty Hauff]

Jim,

Given what 

>>> Jim Wilson <wilson@tuliptree.org> 06/27/03 16:56 PM 

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

Given what you are saying about the transient nature of the insns it would be ideal if the standard pattern used to create the insn list in the first place could somehow be kept with the insn.  I'm assuming that the value of -1 in the insn code is used later by the compiler to know whether to attempt matching on the pattern so that rules this field out????
I was wondering if you could comment on the amount of work that might be involved in adding a new field to the insn definition.  From what I've seen its a pretty convoluted sort of structure and I don't imagine changing it will be easy???

> You could always try calling recog() yourself to set 
the INSN_CODE field.

Let me make sure I understand this... If I call recog() just after the initial RTL generation pass (around when .00.rtl is written and prior to optimizations etc.) this routine should fill in the insn ids with the same code as the insn that was used to create the rtl originally?

Thanks
Marty Moose