Am 02.06.20 um 19:14 schrieb Basil Hussain:
> ; can.c: 451: prev_page = CAN_PSR;
> ; ic: 44: _can_rx_isr_prev_page_65537_99 [k33 lr0:0 so:0]{ ia1
> a2p0 re0 rm0 nos0 ru0 dp0}{unsigned-char auto} = @[0x5427
> {volatile-unsigned-char generic* literal} + 0x0 {const-unsigned-char
> literal}]
> ; genPointerGet
> ld a, 0x5427
> ld _can_rx_isr_prev_page_65537_99+0, a
>
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).
Philipp
_______________________________________________
Sdcc-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sdcc-user
