On Sat, 17 Jan 2015, Jakub Jelinek wrote: > On Sat, Jan 17, 2015 at 01:18:44PM -0500, Hans-Peter Nilsson wrote: > > (Waking up an old thread with my 2 cents due to being a little > > behind on reading...) > > > > On Sat, 6 Dec 2014, Jakub Jelinek wrote: > > > On Sat, Dec 06, 2014 at 09:28:57AM +0100, Uros Bizjak wrote: > > > > > That's already what it does though, did you mean the opposite? Or > > > > > did you > > > > > mean to write "combine" instead of "compare"? > > > > > > > > The above should read "... that existing RTX *combine* pass be updated > > > > ...", thanks for pointing out! > > > > > > Which target actually uses the [(operation) (set (cc) ...)] order in their > > > *.md patterns? Even aarch64 and arm use the [(set (cc) ...) (operation)] > > > order that combine expects, I thought compare-elim was written for those > > > targets? If the vast majority of mds use the order that combine expects, > > > I think it should be easier to adjust compare-elim.c and those few targets > > > that diverge. > > > > The current cc-first order happened more of an accidental > > opinion than an architectural decision as I vaguely recall, when > > asking. We also have the canonical location of a *cc clobber*, > > i.e. last in a parallel. For that reason, it then makes sense > > to have the *cc-setting* last. Changing rebelling ports doesn't > > solve that inconsistency. > > Clobber is clobber, all clobbers come last, so it has nothing to do if > cc set is first or second.
You honestly don't see the benefit of using that order also when there's a cc-setting conceptually in place of a clobber? For targets where most insns set condition-codes (and that don't use the deprecated CC0-machinery), those insns will always be expressed using a parallel with (most often) two members, one being the "main" part of the insn and the other either a (clobber (reg:CC ...)) or a (set (reg:CC ...) ...). There, it doesn't make sense to have a different canonical order. For example: people have already brought up error-prone operand renumbering as a problem, from the perspective of changing *from* the compare-elim (aka. swapped) order. Conversely, if it was declared canonical, you'd have to more often perform otherwise needless operand renumbering in bodies of define_expand's and define_insns (where you hopefully use e.g. define_subst to avoid pattern explosion), when you need to refer to the operands of the "main", non-cc part, for both the set and the clobber substitution. I don't insist on changing compare-elim and matching targets, but declaring the *lack of canonical order* and having gcc cope (by e.g. matching both), as others have suggested, makes sense. brgds, H-P
