Re: [BENCHMARK] runtime impact of fix for target/17390 on i386 targets

[Uros Bizjak <ubizjak at gmail dot com>]

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.