#1832 Performance and code size regression

closed-fixed
5
2012-07-10
2011-08-30
No

I see a significant performance and code size regression between revisions #6760 and #6761. Compilation time is up by about 50%, code size by about 3%. The regression is clearly visible in the graphs at https://sourceforge.net/apps/trac/sdcc/wiki/Philipp%27s%20TODO%20list

Philipp

Discussion

1 2 > >> (Page 1 of 2)
  • Maarten Brock
    Maarten Brock
    2011-08-30

    The regression is probably a result of the removal of hidden casts in SDCCicode.c geniCodeCast(). It used to silently change casts into assignments. And down the road probably only some operations are optimized further.

    Maarten

     
  • Yes, reverting SDCCicode.c makes brings both compilation time and code size back down to #6760 levels.

    Philipp

     
    • labels: --> Icode generator
     
  • What should we do about this bug? It is a serious issue - a 3 % code size increase is a lot: A program previously fitting into a 32K ROM now takes 33K.

    Was the change to SDCCicode.c a bug fix or just a code cleanup?

    Philipp

     
  • Maarten Brock
    Maarten Brock
    2011-09-03

    It is part of a bug fix. Otherwise the fix in SDCCcse.c is not reached.

    IMO it can only come back with positive logic for cases where it really can be applied.

     
  • Fort this file from the runtime library, the change increases the number of iCodes by over 100%.

     
    Attachments
  • For the attached file, we see two types of casts being eliminated:

    1) Casts from
    long-int near* auto
    to
    struct bil near* fixed

    For expression such as
    bcast(a)->b.b0
    where a is a pointer to long and bcast is a macro that casts to struct bil*; however the resulting pointer is used as pointer to unsigned char (there is no iCode being generated for that cast).

    2) Casts from
    volatile-int auto
    to
    volatile-unsigned-int auto
    [I wonder where the volatile comes from, as there's no volatile in the source]

    It seems that casts of type 2) don't do much damage, it's the casts of type 1) that result in the code size increase. Could we bring back the old behaviour for pointer-to-pointer casts? Which types of casts did trigger the bug you fixed?

    Philipp

     
  • This issue is an evenbigger problem on hc08, where I see an over 8% code size increase from #6760 to #6761.

    Philipp

     
  • Let's drop the big one on this mess: lospre, see RFE #3525464.

    Philipp

     
  • Fixed by merging the lospre brnach in revision #8035.

    Philipp

     
1 2 > >> (Page 1 of 2)