>>Still seeing lots of extra SLOCs. Here's another bit
>And this time for a good reason
Yes, it certainly is a good thing to fix the long-standing problems
where breaking from a loop causes some variable to be "lost". I've
personally hit that bug a few times, though not recently.
But I can't see what the reason is for some of these SLOCs. Maybe it's
because I really only look at the generated code and not at the icodes.
But here goes.....
0: sloc0 is used as a 32 bit temporary, after sloc5 was already used for
the same purpose! The peephole optimizer could get rid of sloc0
1: another easy target for the peephole optimizer
4: appears to just hold a copy of sloc7. I really don't understand this one
5: used as a 32 bit temporary in both places.... could eliminate with
peepholes, but not easily
>So, yes, this is a regression but produces more reliable code, and yes, this
>definatly is a case for optimisation.
I could make the peephole optimizer eliminate 0 and 1, which is 6 of the
15 bytes. I might be able to get rid of 5, saving 4 more bytes.... but
it will require two sets of peephole rules to flag each occurance (lines
391-405 and 1054-1071) doesn't depend on the prior value, and then more
peephole rules to eliminate them.
I'll take a shot at some support in the peephole optimizer for checking
for these easy-to-remove ones.