Menu
▾
▴
#2215 Jump by decrement on hc08 / s08
In src/hc08/ralloc2.cc, line 565, we see
OP_SYMBOL (IC_RESULT (ic))->regType == REG_CND;
This obviously is a typo. But the typo masks a bug that needs to be fixed first: We want to change the regType to REG_CND if the result is only used as a jump condition. But ifxForOp only checks if the jump condition is the last use of the result in the iCode sequence.
Philipp
I think this line needs to be removed entirely rather than corrected to an assignment. At least within the context of the hc08/s08 backend, setting regType to REG_CND indicates that the operand exists only within the CPU flags register, so this can only be used by pairs of adjacent iCodes that understand exactly which bit(s) of the flags are used. To have reached this point, we have already established that the current iCode is of the form x=x-1. But the code generator is not prepared for x to be flag bits in this kind of iCode.
If x is a single byte, then the code generator will have used instructions to implement this decrement that will also update the Z flag bit according to a zero or non-zero result that an immediately following if(x) could use. But in this scenario, the Z bit has no associated operand in either the decrement or if iCodes. If that operand explicitly existed, it would be the one that should have regType REG_CND, not x.
I don't quite understand your concern with ifxForOp. Are you advocating that it should also verify that the result is used exactly once?
Yes. I implemented the check in [r9940].
Philipp
Regarding the REG_CND: But the code generator currently does handle the operand as only existing in flags (though all code is generated at the first ic and it works even when regType is not set to REG_CND).
The case directly above used regType REG_CND for this (and so do the otehr backends in similar situations).
So assigning REG_CND to regType seems the consistent thing to do.
Philipp
I want this line fixed, one way or the other. This bug has been lurking here for 4 years now.
Philipp, do you agree with Erik that the line can/should be deleted? Or are you of a different opinion? If so, please explain.
Fixed in [r10755].
Philipp