Alexandre Oliva <[EMAIL PROTECTED]> writes: > > 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.
In general, I completely agree. Of course, correctly modeling the effect on the condition codes really means putting the information in the RTL so that it is exposed to the RTL optimizers. As I said in my reply to Kenner, that implies that many of the insn patterns will have two sets. Unfortunately, most of the RTL optimizers are not prepared to deal with two sets in a single insn pattern. This is arguably a bug, but we can't ignore it. I'm sure you are aware of this. My suggestion for clobbercc in no way invalidates or replaces the existing cc attribute. Any I'm not suggesting that we should add a clobber of the CC to an instruction or alternative which does not clobber the CC. That would clearly be detrimental. I don't know how to handle that in detail; perhaps it would be possible to split the insns after reload into variants which do and do not clobber the CC. Also I'll note that no particular target has to follow the path I'm suggesting here. What I'm after is a way to convert away from cc0 in a reasonable amount of time for all targets. There are several ways to convert away from cc0, and any particular target can follow whichever path seems to make the most sense. > > 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. I'm not proposing any sort of combinatorial explosion. It is not necessary to combine every condition code setting instruction with every branch instruction. The proposal is that most of the combinations will be handled after reload in the NOTICE_UPDATE_CC optimization pass. Incidentally, a processor which can handle reload's requirements without trashing the CC does not need to combine compare and branch instructions. That is just the fast path. > > 2c) Similarly convert setCOND, movCOND, and addCOND instructions. > > And then, there are these, which add to the combinatorial explosion. Same comment. > > 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. Can you spell that out in more detail, up to the point where somebody could start working on it? That description doesn't give me enough to go on. How would this machinery be invoked? How would it be implemented? > > 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. Yes, the point of the clobber is to make scheduling work correctly. In general the compiler currently goes to some effort to keep CC-setters and CC-users together. Adding the clobber means that we can existing mechanisms, rather than relying on mechanisms specialized to cc0. > > 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? Yes, that is what I mean. > Why not use the relatively-common-in-cc0-ports > cc attribute for this purpose? That would be fine. It would be trivial to define clobbercc in terms of cc for ports which have it. Or it can be implemented in a completely different way--the effect of automatically adding the clobbers is what I am after. I'll note that the cc0 port with which I am most familiar is the m68k, which doesn't have a cc attribute. Ian
