Menu
▾
▴
[sdcc-devel] [ sdcc-Bugs-3400613 ] Performance and code size regression
|
From: SourceForge.net <no...@so...> - 2012-07-10 21:10:13
|
Bugs item #3400613, was opened at 2011-08-30 02:13 Message generated for change (Comment added) made by maartenbrock You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3400613&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Icode generator Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Philipp Klaus Krause (spth) Assigned to: Philipp Klaus Krause (spth) Summary: Performance and code size regression Initial Comment: 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 ---------------------------------------------------------------------- >Comment By: Maarten Brock (maartenbrock) Date: 2012-07-10 14:10 Message: That's good news. Just for my curiosity (and maybe yours too) what happens if you reintroduce the hidden casts in SDCCicode.c? Does it indeed have little or no impact? That would indicate this is really tackled. Otherwise it's just compensated by other optimizations. Maarten ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-07-10 14:01 Message: lospre does not remove the casts. However, one of the main problems with the casts was that their presence confused gcse to the point where certain optimizations no longer worked. lospre doesn't get confused that way (and does some optimizations that gcse cannot do anyway). I see a significant reduction in code size and compilation time with lospre. The code size reduction is even more than what we lost in this regression; the compilation time reduction seems to be somewhat less, but it is there. Philipp ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2012-07-10 13:48 Message: Philipp, Can you please elaborate a bit about this? Is the resulting code size and compile time back to what it was before #6761? Does lospre detect the mentioned casts as not necessary for correct code generation and remove them? Maarten ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-07-10 07:45 Message: Fixed by merging the lospre brnach in revision #8035. Philipp ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-05-10 01:37 Message: Let's drop the big one on this mess: lospre, see RFE #3525464. Philipp ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-05-08 01:38 Message: This issue is an evenbigger problem on hc08, where I see an over 8% code size increase from #6760 to #6761. Philipp ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-09-28 08:15 Message: 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 ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2011-09-03 03:49 Message: 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. ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-09-03 03:28 Message: 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 ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-08-30 03:23 Message: Yes, reverting SDCCicode.c makes brings both compilation time and code size back down to #6760 levels. Philipp ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2011-08-30 02:38 Message: 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3400613&group_id=599 |