Thank's for your response, Sunday, 5. Juni 2005 04:16 Ian Lance Taylor wrote: > > The condition-code re-use issue is the point, where, IMO, the link to the > > subreg-lowering 2.) shows up. After, e.g., breaking down a HI mode "sub" > > operation into two QI mode "sub" and "sub-with-carry"s at expand, I > > consider it to be extremely difficult to make the mid-end smart enough to > > identify that a the end of the QI "sub-with-carry" the condition code is > > set according to the corresponding HImode substract operation. For DImode > > operations the mid-end would already need to take 8 (!) Instructions into > > account for finding out what the calculated condition code actually > > represents. This, also, will be a major difficulty when considering Ian's > > suggested optimizer pass after reload. > > I agree that there is a problem here, but it's not clear to me how you > can address it under the current cc0 scheme either. I agree. That problem is existing as well with the cc0 scheme. What I was aiming to suggest is: When it's necessary to work on the CC re-use for the cc0->CCmode transition anyway, let's try to use a path that makes it possible to switch to splitting after expand without facing too much problems.
> > ; Additional "Marker" instructions to be used by GCSE > > (parallel [ > > (use (reg:CC_cc SR)) > > (set (reg:CC_cc SR) (compare:HI (operands[0]) (const_0)) > > (note "please delete the entire embracing parallel instruction before > > register life-time analysis by a new pass: It pretends to use operand[0] > > while in fact this instruction does nothing except from giving hints to > > GCSE.") > > ]) > > (parallel [ > > (use (operands[0])) > > (set (operands[0]) (minus:HI (operands[1]) (operands[2])) > > (note "please delete the entire embracing parallel instruction before > > register life-time analysis by a new pass: It pretends to use operands 1 > > and 2 while in fact this instruction does nothing except from giving > > hints to GCSE.") > > ]) > > I'm not crazy about these marker instructions personally. They are > describing something which I think could be handled via parallel sets > or register notes. The advantage of using actual instructions that I see is, that already the present implementation of the (G)CSE is able to work with the way the information is stored in the marker instruction. And it's, IMO, one possible method for carrying around the information what is actually contained in the zoo of subregs. One would have a bit freedom to choose at which time the information concerning the larger modes is discarded. The reason why (IMO) it is not possible to realize the same functionality with "double set" instructions is, that the condition code generally depends on *all* of the involved subregs. It will be set, however, only by the last instruction of the sequence and this one works only on some *sub*-set of the input operands. I.e. in the example the later "substract with carry" operation (the one working on the most significant byte) would have to pretend to use both, the least significant bytes and the most significant bytes if it included a parallel set for writing the condition code of the entire sequence. The double-set instruction would therefore include an incorrect dependency. This will cause problems, e.g. when the input and output operands of the earlier instructions overlap: Gcc would be forced to hold an unchanged copy of the overwritten input operands in additional registers since it assumes that the last instruction needs them. > The more serious problem I see is that if part of > the subtraction disappears for some reason, the information, however > stored, will be incorrect. How can that problem be avoided? IIUC, the existence of the use statement in the marker instruction prevents that the registers written by the subtraction ever may be marked as "dead" unless the marker instruction itself is removed. I so far have expected that no pass would be allowed to remove an instruction if a later instruction depends on it's result, independent of whether the dependence stems from a (use) statement or the use of the value in a conventional arithmetic or logic operation. Maybe I understood something wrong, but so far I do not see a problem that one would need to avoid. Yours, Björn P.S.: As a detail: I have just realized that the first one of the three marker instructions (the one setting CC according to the compare of operands[1] and operands[2]) probably would have to be placed in front of the two instructions writing (operands[0]). operands[0] and operands[1] possibly could overlap.
