Am 03.06.20 um 13:13 schrieb Philipp Klaus Krause:
> 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
I implemented the optimization in code generation:
https://sourceforge.net/p/sdcc/code/11643/
Philipp
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
