> From: Ian Lance Taylor <ian@airs.com> > Date: 29 Mar 2005 23:05:11 -0500
> Hans-Peter Nilsson <[EMAIL PROTECTED]> writes: > What am I missing? If anything, to post an updated proposal spelling out the bits below! (I.e. nothing as long as there is always a matching automatically generated insn; one with an added (set (reg CC_REG) (unspec ...)) for every insn where NOTICE_UPDATE_CC can presently indicate a "redundant" cc0 setter.) > The gen* files will need to duplicate each > instruction with the clobbercc (or cc0) attribute, You know it, but for the record (needs to be spelled out): every insn "has the attribute". It's a matter of which can have it set to a value that indicates that cc0 can be set to something not explicit in the RTL, i.e. for "clobbercc" it'd be "yes", for "cc0" any attribute value but "explicit" (cc0 users that aren't setters) and perhaps a separate value "manual", where no automatic handling/expansion is applied. > producing one > version which clobbers the cc and one version which sets it to an > unspec. When the new optimization pass deletes an instruction, it > will convert the previous clobbercc instruction to the variant which > sets cc to an unspec. Note that the maintainer does not have to write > an additional patterns to make this work. The information in the last sentence is what I was missing. Good! > Given the above, I don't think there will be pattern explosion, at > least not manually written pattern explosion. FWIW, only manual pattern explosion matters to me as a target maintainer (generic regressions due to explosion can be dealt with target-independently). brgds, H-P
