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.
