Björn Haase <[EMAIL PROTECTED]> writes: > Concerning 1.) Ian Lance Taylor has made a couple of suggestions on how to > make the transition easier for the back-end maintainers. So it seems that > there is already some activity around.
In fact Hans-Peter Nilsson is implementing code to support this transition. I think he started following my suggestions, but has of course modified them in the course of actual implementation. > I would expect that in the rare case that reload needs to access data beyond > the 64-Byte boundary it could be tolerated to expand the memory access to a > sequence of type > "(set (temp_register) (SR)) > (memory_move_instruction_instruction_inserted_by_reload) > (set (SR) (temp_register))" > > One would have to confirm that, but I assume that the remaining passes after > reload would be sufficiently smart to optimize away the two copy operations > for saving and restoring the status register in case that they are not > necessary.? E.g. I think that it is justified to assume that if above > reload-generated memory access is followed by an instruction that clobbers > the condition code, both of the status register operations that are embracing > the memory move would be deleted. Possibly these two instructions would also > be deleted, if the memory move instruction does not clobber the condition > code. Assuming the memory move instruction does not clobber the SR, then I would expect the reload CSE pass to remove the (set (SR) ...). Presumably the temporary register would then be dead, in which case the flow2 pass should remove the (set (temp_register) ...). > 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. > ; Additional "Marker" instructions to be used by GCSE > (parallel [ > (use (reg:CC_cc SR)) > (set (reg:CC_cc SR) (compare: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.") > ]) > (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 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? Ian
