This tells us that the code is not a good candiate for a peephole rule: Both assembler instructions come from the same iCode, so the optimization should be relatively easy to implement in code generation instead. Doing so is still more complex than adding a peephole rule, but has an important benefit: While peephole rules can only do local improvements, changes in the code generator are seen by the register allocator, which can make function-wide decisions based on this knowledge (e.g. in this case that a would no longer need saving at this iCode, if it were to be used for some other variable).
I see, yes, that makes more sense. I had a feeling that my proposed peephole rule was a bit of a hack because it needed so many conditions.
In fact, now I look at it again, it wouldn't work - looking for 'x' substring with notSimilar() would match hex literal address of a register ('0x...'), which would preclude the whole rule!
I implemented the optimization in code generation: https://sourceforge.net/p/sdcc/code/11643/
That's awesome, thanks very much! Regards, Basil Hussain _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
