[PATCH 1/n] Add conditional compare support

Richard Earnshaw rearnsha@arm.com
Thu Oct 24 16:52:00 GMT 2013


On 24/10/13 17:26, Richard Henderson wrote:
> On 10/24/2013 09:24 AM, Richard Earnshaw wrote:
>> On 24/10/13 17:15, Richard Henderson wrote:
>>> On 10/24/2013 01:11 AM, Zhenqiang Chen wrote:
>>>>> Why would you need to encode comparisons in CCmodes?
>>>>> That looks like a mis-design to me.
>>>>
>>>> The CCmodes are used to check whether the result of a previous conditional compare can combine with current compare. By changing it to rtx_code, I can reuse current code (arm_select_dominance_cc_mode_1) to check it.
>>>> The CCmodes are also used to emit the "condition code" for a conditional execution. E.g.
>>>>
>>>>   CC1 (CC_DGEmode) = CCMP (a >= 0, b >= 0)
>>>> ==> cmp a, #0
>>>>          cmpge b, #0
>>>>   CC2 = CCMP ( CC1 != 0, c >= 0)
>>>> ==> cmpge c, #0
>>>> The "ge" is from the mode of CC1 in "CC1 != 0". And the mode of CC2 is not necessary the same as CC1.
>>>
>>> But since you've got the previous comparison operator, why do you need
>>> the same data encoded into the mode?
>>>
>>>
>>> r~
>>>
>>
>> The branch instruction doesn't have that information, only the CC mode.
> 
> Why would the branch instruction need that information?  Havn't we
> already validated whether the comparisons can combine?
> 
> 
> r~
> 
> 

It still needs to put out the right final condition based on the
comparisons that were previously done.  At least traditionaly (in the
existing ARM code) the comparison was just EQ or NE even if the original
tests were inequalities; so the only way to convey the real comparison
information was through the condition code (where select_cc_mode could
work out what was really needed).

I guess if the branch had more information about the comparison, then
the need to encode information through CC mode; but it's always been the
case that the CC mode can modify the final branch condition needed in
the instruction -- consider for example use of bpl vs bge for
non-overflowing >= 0 tests.

R.



More information about the Gcc-patches mailing list