Hans-Peter Nilsson <[EMAIL PROTECTED]> writes: > > 4) For each target which uses cc0: > ... > > 4b) For insn patterns for which some alternatives clobber CC and > > some do not, split the instruction after reload into one > > variant which clobbers the CC and one variant which does not. > > Or just write different patterns which are only recognized > > after reload. > > An IMHO show-stopping problem with 4b is that writing all > matching variants is lots of work; the conversion cost in total > would not be significantly less work for a target than "brute > force" conversion (like the one done in the i386 port) and you'd > get pattern explosion in the .md. At least if you want to avoid > a performance regression.
The only time you need to split an insn is when some of the alternatives in a single insn pattern modify CC and some alternatives do not. I would not expect that to be true of most insns--I would expect that most insns either modify CC or do not, regardless of which alternative is selected by reload. Do you have a counter example? If I am right, then you only to need to split some insns, which should not be all that much work. And you only need to split the insns after reload, which should not cause a performance regression. What am I missing? > > 5) Write a new optimization pass enabled on targets which define > > NOTICE_UPDATE_CC. I think this pass would be run just before > > machine dependent reorg, although perhaps there is a better place > > for it. Walk through the instructions, calling NOTICE_UPDATE_CC on > > each one. When we find an instruction which sets CC_REG, check the > > source of the set with the current CC status, just as > > final_scan_insn does now. If the current CC status is the same, > > delete the instruction which sets CC_REG. > > (Needs to be augmented with:) ... but change the noticed-insn > (into a parallel if not already one) that also sets CC_REG, and > check that the resulting parallel insn is recognized before > going ahead with removing the original cc0-setter. (If you > don't do this step, you'll get in trouble with missing sets of > CC_REG for flow info, and unrecognized-insn ICEs.) If the > resulting insn is unrecognized && ifdef ENABLE_CHECKING, emit a > warning, so the target maintainer notices the opportunity for > optimization (i.e. which was there with the "old" > NOTICE_UPDATE_CC handling). Yes, RTH pointed this out. The gen* files will need to duplicate each instruction with the clobbercc (or cc0) attribute, 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. > But I think this suggestion and similar ones along this line is > doing too much for too little gain. To wit, if you want > matching performance, you still have pattern explosion in the > .md as noted above. Even if performance is unimportant, you > *still* need to tweak the .md and also the .h register macros. Given the above, I don't think there will be pattern explosion, at least not manually written pattern explosion. > And while we're here, a suggestion for the conversion process: > All cc0 targets must have simulators and newlib ports matching > the simplest simtest-howto.html description (drop-in equivalent > for newlib ok, i.e. expands in its own dir and with toplevel > patches to configury, with publically accessible tarball for the > lib) and corresponding sim "baseboard" description. Else, > they'll be obsoleted and removed before any CC0 revolution > (removal of HAVE_cc0 in the middle-end). (Actually the lib+sim > requirement should be applied to all new targets.) Conversion > for a target is considered successful if no regressions with > "make check". Listed maintainers would have conversion rights. Fine with me in principle, but in practice we can't remove the m68k port even though it does not have a simulator in the src tree. Ian