On 11/01/2011 02:59 PM, Hans-Peter Nilsson wrote: > Please, when replying, also send to me, not just the list. > > On Tue, 1 Nov 2011, Paulo J. Matos wrote: >> On 01/11/11 02:43, Hans-Peter Nilsson wrote: >>> >>> Not obvious or maybe I was unclear as to what I alluded? >>> In the below insn-bodies, "sub" is the insn that sets cc0 as a >>> side-effect. >>> >>> Supposed canonical form : >>> >>> (parallel >>> [(set cc_reg) (compare ...)) >>> (set destreg) (sub ...))]) >>> and: >>> (parallel >>> [(set destreg) (sub ...)) >>> (clobber cc_reg)]) > >> That is very strange because if you look into RX or MN10300, they all have >> the >> set REG_CC as the last in the parallel.
Yes. The cc_reg last there is a consequence of the post-reload compare-elim pass. Which wants to splat the CC set on top of the clobber. Thus it must be last. > That'd be a good reason to flip the default...except that the > i386 has it the other way round i.e. as shown above. I think > the main reason is that it just seemed right to those port > authors. Frankly, I'd prefer to flip the default. It does seem to make the most sense. We shan't do that until we tackle... > I'm still thinking of a generic md iterator mechanism (one that > doesn't restrict the form of the expansion in ways getting in > the way with expanding to both a clobber and a set, and in > swapped locations as above), to make the troubles go away... > But maybe expanding them by a pass through e.g. m4 would be > better than cooking up something new there. ... this, so that it can all be done automatically. I think some sort of iterator mechanism is best, much like we automate cond_exec and other sorts of macro-izations. I can imagine a sort of (define_insn_with_flags "name" [(set ...) (set (reg:cc) (...)] "" ...) where we automatically expand to (define_insn "name" [(set ...) (clobber (reg:cc))] ...) (define_insn "name_flags" [(set ...) (set (reg:cc) (...)] ...) or something like that. r~
