Re: [sdcc-devel] Re: SLOC usage, yet again

[Paul <pa...@pj...>]

>
>
>>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.


Paul