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

[Uros Bizjak <ubizjak at gmail dot com>]

Ian Lance Taylor wrote:

> Uros Bizjak <ubizjak@gmail.com> writes:
>
>  
>
> > 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.
> >    
>
> The cse_condition_code_reg pass doesn't walk all the instructions.  It
> walks the basic blocks, and looks at the last instruction in each
> basic block.  When it finds an optimization opportunity, it looks at
> more instructions, but usually only a few more.
>
>
>  
Uh, I was trying to say that cse_condition_code_reg pass is not similar 
to any other CSE pass. Following this, existing post-reload CSE passes 
can not be simply enhanced to handle interdependent AX reg and condition 
code reg eliminations.

The proposed patch works like cse_condition_code_reg. It looks at the 
last instruction, and walks up in instruction chain until it hits CC 
setting instruction. It continues up until it hits the AX setting 
compare. Usually, CC setting insn is just a couple of insns above, and 
the walk stops relatively quickly.

Perhpas the problem could be in the successor blocks. We have to walk 
down the insn chain in hope to find matching CC setting or AX setting 
compare instruction, checking if compare args, AX reg or CC reg are 
clobbered by any instruction on the way. If AX reg and CC reg gets 
clobbered, the walk stops as there is no further optimization possible, 
and - if there are no further FP compares - this usually happens quite 
soon down the  insn chain.

Since this patch only deletes instructions, it can't make run-time 
performance worse. Also, there is no impact on register lives as only 
truly redundant instructions are deleted.

I agree with Steven, that mach-reorg is not a good home for this code 
(after reg-stack pass, we have to emit fstps for eliminated register 
popping compares). Is there a recommended approach (target hooks?)on  
how to call this kind of target-dependent function from RTL passes 
(after first post-reload split)?

Thanks,
Uros.