On Fri, 12 May 2017, Jeff Law wrote: > On 05/11/2017 03:29 PM, Hans-Peter Nilsson wrote: > > The canonical order of insns affecting condition-codes has been > > discussed in the past too. > > > > I was then arguing that the compare should go last, i.e. > > (parallel [(set (reg) (op...)) > > (set (ccreg) (compare (op...) (const_int 0)))]) > > for simplicity of processing together with an alternative that > > clobbers (i.e. same location in the parallel), as the canonical > > order of clobbers in a parallel is that they always go last. > > (IIRC from that distant past, transforming a cc0 target to > > "ccreg" required at least three variants: the "naked" insn > > (pre-reload?), the parallel with a clobber of ccreg, and the > > actual use of ccreg; as above.) > > > > Anyway, people seem to drift towards the ccreg-last variant for
(miswrite: ccreg-*first*, as opposed to the above) > > some reason or another every time this is brought up; this time > > it seems the single reason is that some existing pass expects or > > generates this, using the order that causes the minimal fallout. > > (Maybe it's the same pass...) Not sure that's a good base for > > decisions. > > > > Whatever you do in the end, *please document the canonical > > order* in the RTL documentation. > I think what's driving the decision is more a desire not to muck with x86 and > aarch64 and instead place the burden to change on the less popular ports. > > Though I must admit i prefer the cc setting last since that mirrors how we > typically do things with clobbers of the cc register. IOW. > But yes, we definitely should document the final canonical ordering. Is that about to also happen? I foresee in another half-a-dozen years, and *this* iteration is forgotten, someone bothered enough to argue eloquently coming around, doing rtl-level-maintenance, maybe a new pass (ok maybe not a *new RTL-pass* :) sees that order as wrong for the reason listed above, and does the legwork to switch the order around. It will be ok to change it again then, because the order just happened this time because of minimal-edit-reasons, right? Noone can argue that it was a thoughtful deliberate change that we bothered to document, to stay consistent? ;) brgds, H-P
