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. 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. > I wonder if it has anything to do with > the fact that in these backends the set of the REG_CC only shows up after > reload. Right, it'd only matter where (also) GCC cooks up combinations (which IIRC it doesn't if the register is only exposed post-reload), not where only the port emits them. N.B., it *could* very well be that I misremember about the canonical form, but it seems neither of us bother to search the archives, so never mind. ;) ...oh wait, see the comments at combine.c:2824 and 3030 r180744. I can't find anything in the docs, but that might just be my grep-fu failing. 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. brgds, H-P
