From mboxrd@z Thu Jan 1 00:00:00 1970 From: fche@redhat.com (Frank Ch. Eigler) To: dje@transmeta.com (Doug Evans) Cc: , cgen@sources.redhat.com Subject: Re: [patch][rfa] Ordering insns in hash chain for cgen disassemblers Date: Thu, 15 Nov 2001 12:42:00 -0000 Message-ID: References: <3BF3F9AE.8070907@redhat.com> <15348.168.750723.846784.cygnus.local.cgen@casey.transmeta.com> X-SW-Source: 2001-q4/msg00034.html Message-ID: <20011115124200.jipMPmR980TNImrpATWP4vf_w_N8ZhRAmpwiY8nQGnA@z> dje wrote: : [...] : I'm not going to argue for it's removal but fwiw it slightly bothers me. : I worry it's just going to cause headaches. Yeah, I worried too, for a little while. : [While not being the only cause of the worry, question: how will this : sort play with ifield assertion support when it's added, What value do you see for the ifield-assertion mechanism (the "(andif (eq FOO 0) ...)" clauses in derived-operands, right?), beyond what the encoding fields ("+ (f-FOO 0) ...") can/should provide? As it is, RTL-rich code appears legal in too many contexts. : and the user's expectation that things are picked based on order in : the file. [...] IMO, such expectations are just desperate measures to try to get around some cgen limitations. As those limitations start to disappear (and brolley is going to work on one of the most annoying: insn encoding special cases), these measures will no longer be needed. (Thanks for still keeping an eye on cgen!) - FChE