On Sat, 25 Apr 2020, Eric Botcazou wrote: > > I very much disagree with this. I think my approach was possibly the > > only viable one, and definitely the most sensible one for this target. > > Not only is there nothing meaningful to be gained from separating cc > > setters and users on m68k given that almost all instructions (including > > moves) clobber the flags, it is not really an actively maintained target > > and any more adventurous approach would have introduced many more > > possibilities for error. Generating exactly the same code as before as > > much as possible was the correct goal IMO. > > Fair enough, but IMO the constraint that almost all instructions (including > moves)
(...except to address registers, at least move and add, AFAICS.) > clobber the flags is not sufficient (alone) to justify this approach, > as it forces you to use an ad-hoc mechanism to eliminate redundant compares > instead of the dedicated RTL pass, and may hinder scheduling in the case where > it would be useful to schedule instructions, e.g. floating-point instructions, > between the CC setters and the CC users. My experience tranforming the CRIS target (on the vendors/axis/cris-decc0 branch, waiting for the next phase 1) which is much like m68k in the cc0 regard, makes me agree with Eric. I was positively surprised with the quality of the cmpelim pass! But, I haven't got around to do actual measurements so that's just from initial observations. The m68k approach just didn't seem attractive to me and FWIW is a no-starter for targets with delay-slots like CRIS (unlike AVR). I wouldn't go with the m68k approach for a "current" target. brgds, H-P
