#3976 unexpected warning "conditional flow changed by optimizer: so said EVELYN the modified DOG"

[sverx]

I got the "conditional flow changed by optimizer: so said EVELYN the modified DOG" both with the official 4.5.0 release and with the latest snapshot build (#16449), on Linux

SDCC : mcs51/z80/z180/r2k/r2ka/r3ka/r4k/r5k/r6k/sm83/tlcs90/ez80/z80n/r800/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8/pdk13/pdk14/pdk15/mos6502/mos65c02/f8/f8l TD- 4.5.24 #16449 (Linux)

just performing a simple integer division, for instance this:

unsigned char func (unsigned char n) {
  unsigned char k=n/32;
  return (k);
}

void main (void) {
  func(5);
}

and simply compiling it with sdcc -c -mz80 main.c.

Note that anyway the generated code looks fine to me.

[Philipp Klaus Krause]

Not sure if this is really a bug. Though I wonder if those EVELYN warnings are really worth it; IMO they give too many warnings for cases where optimizing conditional flow is totally fine.

[sverx]

So far I had never before seen them appearing when there was actually no conditional flow change, and I wonder what flow change had been applied here in the k=n/32 expression.
But yes, technically that's not a bug, but I felt I wanted you to know about this anyway and the bug tracker is probably the better place for such issues anyway.

[Philipp Klaus Krause]

I think what happens here is: integer promotion makes the operands of the division into int. Then the optimization for divisions by power of 2 transforms the int division into a conditional addition followed by a right shift. Then later optimizations notice that the left operand can never be negative, so the conditional addition gets optimized out, resulting in the warning.

In general, there are many situations, where control-flow changes are to be expected, but we still can get warnings:

• Control flow introduced by earlier optimizations (such as your case)
• Control flow in macros
• Control flow in inlined functions

Maybe we should try to disable the EVELYN warnings for all those. I'll leave the ticket here for now, but might move it to the feature request tracker after thinking about which one is better for this issue.

[sverx]

Makes sense! Thanks for looking into it! :)