On 06/25/14 10:02, Kai Tietz wrote:
2014-06-25 17:50 GMT+02:00 Richard Henderson <r...@redhat.com>:
On 06/25/2014 08:28 AM, Jeff Law wrote:
Ask an ARM maintainer if the new code is actually better than the old code.
It isn't.
It appears that with the peep2 pass moved that we actually if-convert the
fall-thru path of the conditional and eliminate the conditional. Which, on the
surface seems like a good thing. It may be the case that we need to twiddle
the test. Not sure yet.
Looking at the final code in the pr, it looks like we if-convert both ways,
just with changed condition on the test.
It looks like there are at least 3 peepholes in the arm backend that match
compare+branch with a scratch register that are affected by this. I don't
think it's reasonable to expect a peephole to match compare + n cond_exec
insns, so running peep2 before if-conversion would seem to be called for.
Kai, why does your indirect jump peephole require pass_reorder_blocks? It
seems to me that instead of moving peephole2 down, we could move
duplicate_computed_gotos up.
r~
We need the peephole2 pass after reorder_blocks due we move in that
pass the jump
...
(code_label 54 52 55 5 8 "" [0 uses])
(note 55 54 56 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(jump_insn 56 55 57 5 (set (pc)
(reg/f:DI 0 ax [orig:83 D.3469 ] [83])) 638 {*indirect_jump}
(expr_list:REG_DEAD (reg/f:DI 0 ax [orig:83 D.3469 ] [83])
(nil)))
(barrier 57 56 58)
....
into each bb, so it can be resolved to an indirect jump on memory.
But I think Richard's question was can we move up
duplicate_computed_gotos since that's the code which I'd expect to make
this transformation. Then you run peep2 immediately after
duplicate_computed_gotos.
Jeff
