Supporting a right operand for GET_VALUE_AT_ADDRESS would result in more efficient code genated for the hc08, which has a suitable x-relative addressing mode. This would help with aggregate and union accesses.
This one is probably the on eoptimization with the highest gain among teh easy-to-implement ones. It would trasform code like
ldx #_spm_sprites_list, x
Reducing code size from 13 to 5 bytes. And register a is freed, so it can be used for other purposes. This and similar ones are very common code sequences.
I've implemented the case for a right operand literal in #7741. Still left is the more complicated case of your example, where the right operand would be a rematerializable address of a variable (but I did included support in the low-level loadRegIndexed() to handle this possibility later.)
With revision #7856, it will handle rematerializable addresses too. However, loop invariance optimization and/or CSE conspire in some cases to move the addition iCode away from the GET_VALUE_AT_ADDRESS iCode, which then leaves an iTemp live across a larger span and is likely to be spilled. Need to find a good away to either prevent to movement of the original addition iCode or determine that the cast/assignment it is turned into can be safely moved back so that the iTemp can be assigned hx instead of spilling. I'll work on optimizing this after the release.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.