#3144 The optimizer result is influenced by unrelated code

[Michael Mayer]

In some cases the code optimizer is influenced by totally unrelated code following later. Example code:

int array[4];

void space_efficient(unsigned char n, int val)
{
    array[n] = val;
}

void missed_optimization(unsigned char n, int val)
{
    array[n] = val;

    __asm__("nop");
}

compiling using the latest snapshot 11925:

$ /opt/sdcc-11925/bin/sdcc -v
SDCC : mcs51/z80/z180/r2k/r2ka/r3ka/gbz80/tlcs90/ez80_z80/z80n/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8/pdk13/pdk14/pdk15 4.0.4 #11925 (Linux)
published under GNU General Public License (GPL)
$ /opt/sdcc-11925/bin/sdcc -mstm8 -c indirect.c

The first function requires 10 bytes and 9 cycles for the array access:

      000000 7B 03            [ 1]   59         ld      a, (0x03, sp)
      000002 5F               [ 1]   60         clrw    x
      000003 97               [ 1]   61         ld      xl, a
      000004 58               [ 2]   62         sllw    x
      000005 16 04            [ 2]   63         ldw     y, (0x04, sp)
      000007 DFu00u00         [ 2]   64         ldw     ((_array + 0), x), y
      00000A 81               [ 4]   66         ret

The second function requires 11 bytes and 11 cycles for the very same access:

      00000B 7B 03            [ 1]   73         ld      a, (0x03, sp)
      00000D 5F               [ 1]   74         clrw    x
      00000E 97               [ 1]   75         ld      xl, a
      00000F 58               [ 2]   76         sllw    x
      000010 1Cr00r00         [ 2]   77         addw    x, #(_array + 0)
      000013 16 04            [ 2]   78         ldw     y, (0x04, sp)
      000015 FF               [ 2]   79         ldw     (x), y
      000016 9D               [ 1]   81         nop
      000017 81               [ 4]   83         ret

I suppose that this difference is caused by the optimizer.
Using asm is not the only way to trigger this effect. I found it in a more complex situation where a totally unrelated variable access about 5 lines of c code above the array access triggered this behaviour. If required I could send that test case, but it includes more dependencies.

[Philipp Klaus Krause]

I'd like to see your other example.

However, I wouldn't consider this to be a bug, as the generated code is still correct.

The use of inline asm indeed disables some optimizations, similarly to the use of volatile. Different users apparently have different expectations there.

[Visenri]

I've seen other cases of this, and many times it is because the parsing done in peep.c is not always perfect, that's why I created the heavily modified peep.c uploaded here:
https://sourceforge.net/p/sdcc/patches/290/

Please send me your cases or try my patches to see if the cases get better optimization.

Anyway, to allow optimization having inline asm you have to include "--peep-asm" to your command line.

The problem is with the original peep.c the parser is very picky, if you have different formatting than the compiler output (different number of spaces, register in uppercase...), anything can happen (always on the safe side, optimization is not applied).
With my patched version I have not found any case being parsed incorrectly (handwritten or compiled output), so optimizations are always applied when possible.