Hello Steven! > And FWIW, it is IMHO bad practice in general to just add new passes, > instead of investigating why existing passes don't do the job and how > they can be enhanced to do the job better.
There is no post-reload cse_condition_code_reg () pass, so perhaps we have to add one. A cse_condition_code_reg () walks all instructions by itself, so I'm not sure if some existing post-reload CSE pass could be enhanced. > It's also not a particularly great idea to duplicate a lot of code (like > you did, from the CC-cse pass), and I thought machine-specific > optimization passes are a no-no unless there really, _really_ is no way > to do the optimization elsewhere in the shared code. I don't think a lot of code is duplicated, perhaps only checks for clobbered registers between two insn (that are necessary). The insn walking code is quite generic. Regarding specific i386 implementation: fp_jcc_* patterns are splitted to their final sequences somewhere in flow2 pass, so I think the best place to put a generic CC-cse pass is somewhere between _.flow2 and _.csa pass. The benefit of this approach would be correct calculation of register lives by following passes, and this way we could get rid of extra fstp instructions that are necessary in post-regstack optimization pass, if popping compare insn was removed. However, proposed code is so much i386 target specific, that I was under impression that it could be put into machine specific pass. I think that this code is not of any use to other targets, so perhaps this code should be implemented as a target hook that is called somewhere after post-reload split in _.flow2 pass? (BTW: Is there already appropriate target hook availabe that is called after post-reload split?) Thanks for your suggestions, Uros.