From: SourceForge.net <no...@so...> - 2012-05-08 08:38:24
|
Bugs item #3400613, was opened at 2011-08-30 02:13 Message generated for change (Comment added) made by spth 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: Open Resolution: None Priority: 5 Private: No Submitted By: Philipp Klaus Krause (spth) Assigned to: Nobody/Anonymous (nobody) 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: 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 |