[patch passes.def]: Fix regression on ARM PR/61608

[Ramana Radhakrishnan]

[Apologies about the duplicates to folks - resending to make this hit 
the lists]

On 25/06/14 16:28, Jeff Law wrote:
> On 06/25/14 09:04, Kai Tietz wrote:
>> 2014-06-25 16:04 GMT+02:00 Jeff Law <law@redhat.com>:
>>> So why is the peephole not working in its current location?
>>>
>>> Jeff
>>
>> Hi Jeff,
>>
>> that is what I read out of dumps:
>>
>> If peephole2 is executed early we see following pattern transformation:
> [ ... ]
> Ask an ARM maintainer if the new code is actually better than the old code.
>
> 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.


No, we don't need to twiddle the test. The test is good as it is today
as we caught a potential size regression. (Prima-facie the test itself
doesn't show an actual size regression because of padding but you can
see the replacement of a 2 byte instruction with a 4 byte instruction)

These peepholes that were in there gave 0.1% in CSiBe for Thumb2 as per
the original patch 
(https://gcc.gnu.org/ml/gcc-patches/2010-06/msg02518.html). The 
if-conversion happened anyway afterwards regardless of where the pattern 
was but the key here was the conversion of the 4 byte instruction to a 2 
byte instruction.

Looks like the all the peephole2's that have if_then_else's (5 patterns
today) also need to develop a cond_exec variant where possible in the
ARM backend.

It seems unfortunate that the backend has to handle each of the possible 
pattern classes that may be conditionalized by the cond-exec pass and we 
potentially maintain a list of patterns in sync with anything that can 
be conditionalized.

At first glance this looks ugly to "work around" in the backend.

regards
Ramana

>
>
> Jeff
>
>
>