🚀 go-pugleaf

From article <1993Jan21.002358.25085@ccu1.aukuni.ac.nz>, by tantrum@ccu1.aukuni.ac.nz (Michael Tantrum):
>    Here's a trick for young fools...  I've found a bug in the optimizer.  I
>    hope this isn't old news.
 .
>    I have all the optimizations turned on, including global common
>    subexpression elimination.  The code is fine until the last two
>    statements.  Then, the compiler generates:
> 
>      ...   /* code to compute array address */
>    mov ax,[bp-0c]    /* i.e. the value of i */
>    inc ax            /* now ax = i + 1 */
>    mov es:[bx],ax    /* put the result into the array */
> 
>    cmp ax,limit
>    jl startOfLoop
> 
>    ... So the result is, the variable is never stored back!  i is stuck at
>    zero, never incremented.  Bummer!  Looks like the live range analysis
>    goofed.

I've seen this before, and this is (partly) while one of the very few rules
I have for coding around here applies to what optimisations are to be used.
The permitted ones are limited to the most basic optimisations.

In the end, if the code is well written, the optimisations will only help
by about 5%. Much better optimisation can be done by improving the code.
At a 5% speed improvement, the risk of optimiser induced bugs creeping
in (including some subtle ones that might escape QA) is far too high.
--
_______________________________________________________________________________
troy@cbme.unsw.EDU.AU	      Overworked, overcommited and always multitasking.
Opinions expressed are not those of the CBME or UNSW, but are my opinions only.
You are free to adopt them.   I suggest you adopt them.    You will adopt them!