This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch passes.def]: Fix regression on ARM PR/61608
- From: Kai Tietz <ktietz70 at googlemail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Richard Henderson <rth at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 25 Jun 2014 19:53:12 +0200
- Subject: Re: [patch passes.def]: Fix regression on ARM PR/61608
- Authentication-results: sourceware.org; auth=none
- References: <CAEwic4Ycv_asbomwC2gpcjDLQmJ9LO023PBFtrmKA=9BXf58ag at mail dot gmail dot com> <53AAD6F1 dot 2080707 at redhat dot com> <CAEwic4bOmzQ_EbdSZKtNgxhdwes-7wn5PoyUcOBUv=hyZhrhkw at mail dot gmail dot com> <53AAEA8C dot 80303 at redhat dot com> <53AAEFC4 dot 7070008 at redhat dot com> <CAEwic4ZCP5vnS2Ry6CmM4XdMffq=CkAFHhvKTp=0VVmpKLqopw at mail dot gmail dot com> <53AB03C5 dot 2060207 at redhat dot com>
2014-06-25 19:15 GMT+02:00 Jeff Law <law@redhat.com>:
> On 06/25/14 10:02, Kai Tietz wrote:
>>
>> 2014-06-25 17:50 GMT+02:00 Richard Henderson <rth@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
>
The pass of question on ARM isn't the duplicate_compute_gotos pass.
It is the if-after-reload pass.
I tested it by moving it.
Kai