On Mar 23, 2005, Ian Lance Taylor <ian@airs.com> wrote: > 2a) Define the clobbercc attribute to be "yes" for each insn which > changes the condition codes unpredictably. Typically the > default would be "yes", and then either clobbercc would be > written to use cond to select instruction for which it should > be "no", or those instructions would be marked specifically.
Currently, mn10300 and h8300 use `cc' as the attribute to indicate how an instruction affects cc0. If you look at say mn10300 closely, you'll see that different alternatives for several instructions have significantly different behavior regarding cc0. For example, `none' and `none_0hit' don't change flags at all, where `set_*' change some flags, and `compare' and `clobber' sets all flags. Replacing them all with a clobber is sub-optimal, because some alternatives don't really clobber cc0. I'm not sure how much of a problem this would be, or even if it actually makes any difference, but it feels like it would be appropriate to somehow model such conditional clobbering and, perhaps, even the actual operation performed on cc0. > 2b) Convert conditional branch instructions from separate > cmpMODE/bCOND instructions to a single conditional branch > instruction, either by saving condition codes in cmpMODE or > tstMODE or by using cbranch. The problem here IIRC is a combinatorial explosion on the number of alternatives for the now-merged compare&branch instructions. Have a look, for example, at the cc0-setting patterns on h8300.md, including the zero-extend and zero-extract ones. There are many of them, with operands that aren't easy to get into a single cbranch instruction. > 2c) Similarly convert setCOND, movCOND, and addCOND instructions. And then, there are these, which add to the combinatorial explosion. > At this point we have eliminated cc0 for the target. The generated > code should be correct. I think a better approach would be to enable cc0 to be used in patterns, but have some machinery behind the scenes that combines expanders for cc0-setting and cc0-using instructions, creates the post-reload splitters and makes the actual insns conditional on reload_completed. Then one can still model the port in the most natural way, but not overburden the rest of the compiler with cc0 support. > The instruction which sets the condition > codes will be kept in synch with the instruction which uses the > condition codes, because most other instructions will have an > automatically inserted clobber. If you have combined all cc0 setters and users, the clobber is mostly pointless, at least in the absence of scheduling. Sure enough, when the time comes to split the setters and readers, they must be in place, so perhaps the addition of the clobbers could be taken care of at that time as well, taking cc alternatives into account? The same machinery that adds the combined patterns and splitters could also generate splitters for the potential-cc0-setting patterns to be applied at that same time, adding a clobber or set pattern based on the alternative selected by reload, according to rules specified by a mechanism equivalent to NOTICE_CC_UPDATE. Then we'd run new code (the new pass you suggested) to find redundant cc0 setters and remove them. > The main ideas here are to use the clobbercc attribute to avoid having > to modify every single instruction, How does it avoid this? On cc0 targets, almost every single instruction modifies the flags anyway. How does having to add the clobbercc attribute help? Or do you mean we'd introduce the clobbercc attribute with a default to yes, and then set it to no on the rare instructions/alternatives that don't clobber it? Why not use the relatively-common-in-cc0-ports cc attribute for this purpose? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
