[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #28 from matz at gcc dot gnu dot org 2010-04-06 10:34 --- I don't think we should fix the double-accounting bug for the 4.5 series, when we tried it on SPEC it caused several regression, meaning we would need much more fine-tuning. We have time for that for 4.6. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #29 from hubicka at ucw dot cz 2010-04-06 10:46 --- Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852 I don't think we should fix the double-accounting bug for the 4.5 series, when we tried it on SPEC it caused several regression, meaning we would need much more fine-tuning. We have time for that for 4.6. Well, we need to compensate for overall unit growth then, I will do so at pretty-ipa so it will get some testing and see how much trouble it causes. I am fine with this not being fixed in 4.5.x as long as we won't run into real world testcase where double counting causes explosion of unit size. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #30 from steven at gcc dot gnu dot org 2010-04-06 10:56 --- I think it is a really, really bad signal if a bug like this, where the revision that introduced the issue was identified 9 months ago, remains unfixed for GCC 4.5. I, for one, wouldn't care hunting down revisions that introduce regressions in stage1 anymore, if component maintainers and release managers just postpone fixing the issue until it is too late to fix for a release. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #31 from rguenther at suse dot de 2010-04-06 11:00 --- Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852 On Tue, 6 Apr 2010, steven at gcc dot gnu dot org wrote: --- Comment #30 from steven at gcc dot gnu dot org 2010-04-06 10:56 --- I think it is a really, really bad signal if a bug like this, where the revision that introduced the issue was identified 9 months ago, remains unfixed for GCC 4.5. I, for one, wouldn't care hunting down revisions that introduce regressions in stage1 anymore, if component maintainers and release managers just postpone fixing the issue until it is too late to fix for a release. Well, the fix doesn't fix this bug. There's no patch to fix this bug (yet). Also 0.5% code size increase doesn't look important enough to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #32 from hubicka at ucw dot cz 2010-04-06 11:05 --- Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852 I think it is a really, really bad signal if a bug like this, where the revision that introduced the issue was identified 9 months ago, remains unfixed for GCC 4.5. This particular bug should not affect -Os scores at all as discussed earlier. Overall unit growth limits will never hit at -Os since we never enlarge unit size. I spent fair amount of time tracking down the individual CSiBE code size increases and fixed most of them. At the moment, I believe, the only remaining issue is bzip2 size growth. The inlining decisions here are sane at the local level as inliner sees them, just the resulting binary gets bigger. Inling is a heuristic even at -Os and we can't expect it to work in all cases. Here the old inliner got lucky by simply not accounting any stores/loads as real instructions allowing the functions to be inlined at letting later optimizers to produce smaller code. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #33 from matz at gcc dot gnu dot org 2010-04-06 11:09 --- Steven, please note that this PR was proposed WONTFIX for 4.5 already in comment #15. The discussion after that was about something that is only slightly related to this bug, something that wouldn't actually affect this very bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #34 from rguenth at gcc dot gnu dot org 2010-04-06 11:20 --- GCC 4.5.0 is being released. Deferring to 4.5.1. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.5.0 |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #35 from steven at gcc dot gnu dot org 2010-04-06 11:32 --- If your discussions are only slightly related to this bug and don't affect -Os, then why are you having that discussion here? Anyway. If this is WONTFIX for GCC 4.5, then it should be marked as such (remove 4.5 regression from subject, open new PR for other issue, whatever). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #23 from hubicka at ucw dot cz 2010-04-03 21:02 --- Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852 1) overall_size is reduced twice for the same function, once in cgraph_clone_inlined_nodes, once in cgraph_mark_inline_edge (which calls the former), this leads to double accounting Hmm, yep, it is bug here and I guess it makes tramp3d unhappy since it relies on the overall unit growth. I will try to fix this and retune to see if this can be used to help the CSiBE regression that also might be related to this thinko. 2) cgraph_check_inline_limits checks the wrong size against the PARAM_LARGE_FUNCTION_INSNS parameter, it needs to use the original size, not the one estimated after inlining. Well, PARAM_LARGE_FUNCTION_INSNS was meant to let small functions to grow as much as they want until the threshold is hit, so size after inlining makes sense here. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #24 from rguenther at suse dot de 2010-04-03 21:13 --- Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852 On Sat, 3 Apr 2010, hubicka at ucw dot cz wrote: --- Comment #23 from hubicka at ucw dot cz 2010-04-03 21:02 --- Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852 1) overall_size is reduced twice for the same function, once in cgraph_clone_inlined_nodes, once in cgraph_mark_inline_edge (which calls the former), this leads to double accounting Hmm, yep, it is bug here and I guess it makes tramp3d unhappy since it relies on the overall unit growth. I will try to fix this and retune to see if this can be used to help the CSiBE regression that also might be related to this thinko. 2) cgraph_check_inline_limits checks the wrong size against the PARAM_LARGE_FUNCTION_INSNS parameter, it needs to use the original size, not the one estimated after inlining. Well, PARAM_LARGE_FUNCTION_INSNS was meant to let small functions to grow as much as they want until the threshold is hit, so size after inlining makes sense here. But the the code as-is allows unlimited growth of a function (well, by PARAM_LARGE_FUNCTION_GROWTH for each inlining; the limit is basically PARAM_LARGE_FUNCTION_INSNS * (1 + PARAM_LARGE_FUNCTION_GROWTH/100) ^ n with n being the number of functions we inline into the function). So it's not really a limit of the growth but of the growth rate ;) Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #25 from hubicka at ucw dot cz 2010-04-03 21:19 --- Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852 But the the code as-is allows unlimited growth of a function (well, by PARAM_LARGE_FUNCTION_GROWTH for each inlining; the limit is basically PARAM_LARGE_FUNCTION_INSNS * (1 + PARAM_LARGE_FUNCTION_GROWTH/100) ^ n with n being the number of Size after inlining decide whether we want to apply PARAM_LARGE_FUNCTION_GROWTH or not. When we decide so (based on overall function size), the limit is computed based on size without inlining. So PARAM_LARGE_FUNCTION_INSNS only adds a buffer for small functions, but should not interfere with the growth limits once function gets bigger than that. (at least it is intended to work this way, I will double check the implementation after returning) Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #26 from hubicka at ucw dot cz 2010-04-03 21:20 --- Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852 As for history, I oriignally had only the perentage limits at place, but then found that they behave really erratically on small units and small functions. (especially in kernel source where you have tiny units with two functions that needs to be inlined one to other). So I added this large function/unit thresholds. They should be symmetric for functions and units. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #27 from hubicka at ucw dot cz 2010-04-03 21:39 --- Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852 And after checking the code, I think it is correct. I.e. limit is computed on size before inlining of caller or callee (this is to allow large callees to be inlined into tiny wrappers). So overall limit for size after inlininig is max(LARGE_FUNCTION_INSNS, orig_size + orig_size * LARGE_FUNCTION_GROWTH) that seems sane to me. Thinking more about the double accounting bug, it probably should not affect the -Os compilation too much since we should not be inlining anything large at first place. Still will make a fix at monday and probably try to push it at least to 4.5.1 or so. It definitly allows to construct units where we let a lot more growth than we are supposed so. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-03-28 15:46 --- (In reply to comment #15) I've been discussing this on IRC a while ago with Richard Guenther, but forgot to add a record. It seems that for 4.5, it is best to leave inlining heruistics as it is. THe code size regression come mainly from bzip that is excercising kind of typical bad luck scenario. Other known problem in 4.5 inlining is tramp3d where we now deliver worse than best known performance, but still not worse than one of 4.4. I spent some time playing with this and only way to get 4.5 inliner to solve these faults is to add new parameter that allows early inlining to inline forwarder functions that do increase code size estimates by small amount. This helps to solve both tramp3d and bzip problems but also cause code size issues in some benchmarks (mostly not regressions over 4.4) and is quite ugly. Since re-tunning heuristics needs significant amount of effort and it was done earlier in stage1 of 4.5 after merging changes from pretty-ipa, it seems better to leave as it is now. Also after LTO merge it seems, according to results posted by Vladimir Marakov, that the inliner is actually perfomring very well compared to other compilers. For 4.6 I do have number of plans. With FRE in early optimization queue we invalidate need for some of early inlining and also IPA stuff should be making us less dependent on inling overall. But I would propose this PR to be wontfix for 4.5. Indeed. There is also some miscounting of overall unit size, Micha has a patch for that (but it completely chokes tramp3d results). There is also the early inliner cleanups I have done at some point. Thus, I suppose we can look at this early during 4.6 development again. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, matz at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #17 from hubicka at ucw dot cz 2010-03-28 16:33 --- Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852 Indeed. There is also some miscounting of overall unit size, Micha has a patch for that (but it completely chokes tramp3d results). There is also the Where is the patch? early inliner cleanups I have done at some point. Thus, I suppose we can look at this early during 4.6 development again. Well, those should not affect the resulting inlining, right? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #18 from rguenther at suse dot de 2010-03-28 16:43 --- Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852 On Sun, 28 Mar 2010, hubicka at ucw dot cz wrote: --- Comment #17 from hubicka at ucw dot cz 2010-03-28 16:33 --- Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852 Indeed. There is also some miscounting of overall unit size, Micha has a patch for that (but it completely chokes tramp3d results). There is also the Where is the patch? Somewhere - you have to as Micha. early inliner cleanups I have done at some point. Thus, I suppose we can look at this early during 4.6 development again. Well, those should not affect the resulting inlining, right? In theory not. In practice it removes the iteration if I remember correctly. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #19 from hubicka at ucw dot cz 2010-03-28 16:56 --- Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852 There is also some miscounting of overall unit size, Micha has a patch for that (but it completely chokes tramp3d results). There is also the Where is the patch? Somewhere - you have to as Micha. I think I saw one but it was wrong. I would be interested to at least know what this patch is about :) In theory not. In practice it removes the iteration if I remember correctly. Yes, but that should not affect the metrics (hopefully) Anyway the 4.6 inliner will probably again behave quite differently - I want to get FRE early, possibly get partial inlining done and we will have IPA AA that all affects effectivity of inlining. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #20 from rguenther at suse dot de 2010-03-28 17:00 --- Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852 On Sun, 28 Mar 2010, hubicka at ucw dot cz wrote: --- Comment #19 from hubicka at ucw dot cz 2010-03-28 16:56 --- Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852 There is also some miscounting of overall unit size, Micha has a patch for that (but it completely chokes tramp3d results). There is also the Where is the patch? Somewhere - you have to as Micha. I think I saw one but it was wrong. I would be interested to at least know what this patch is about :) It's about not accounting static called once functions twice when decreasing overall unit size. In theory not. In practice it removes the iteration if I remember correctly. Yes, but that should not affect the metrics (hopefully) Anyway the 4.6 inliner will probably again behave quite differently - I want to get FRE early, possibly get partial inlining done and we will have IPA AA that all affects effectivity of inlining. Of course. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #21 from hubicka at ucw dot cz 2010-03-28 17:30 --- Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852 I think I saw one but it was wrong. I would be interested to at least know what this patch is about :) It's about not accounting static called once functions twice when decreasing overall unit size. Ah, I saw that one and I think it was wrong (and that is also why it regressed on tramp3d). I will dig it out. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #15 from hubicka at gcc dot gnu dot org 2010-03-07 20:37 --- I've been discussing this on IRC a while ago with Richard Guenther, but forgot to add a record. It seems that for 4.5, it is best to leave inlining heruistics as it is. THe code size regression come mainly from bzip that is excercising kind of typical bad luck scenario. Other known problem in 4.5 inlining is tramp3d where we now deliver worse than best known performance, but still not worse than one of 4.4. I spent some time playing with this and only way to get 4.5 inliner to solve these faults is to add new parameter that allows early inlining to inline forwarder functions that do increase code size estimates by small amount. This helps to solve both tramp3d and bzip problems but also cause code size issues in some benchmarks (mostly not regressions over 4.4) and is quite ugly. Since re-tunning heuristics needs significant amount of effort and it was done earlier in stage1 of 4.5 after merging changes from pretty-ipa, it seems better to leave as it is now. Also after LTO merge it seems, according to results posted by Vladimir Marakov, that the inliner is actually perfomring very well compared to other compilers. For 4.6 I do have number of plans. With FRE in early optimization queue we invalidate need for some of early inlining and also IPA stuff should be making us less dependent on inling overall. But I would propose this PR to be wontfix for 4.5. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #14 from ramana at gcc dot gnu dot org 2009-12-09 17:09 --- (In reply to comment #13) I am just re-testing it on vangelis with size estimates ignoring it. Honza - Any updates on this ? Ramana Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #13 from hubicka at ucw dot cz 2009-07-02 10:10 --- Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852 OK, on i386 it has some effect according to our nightly tester it is 3524421-3510754. The size used to be as low as 3431090 so it is just small improvement. I guess I will commit the patch anyway as it is quite obvious fix. The other problem might be the likely_eliminated_by_inlining_p predicate that is very optimisitic. This predicate makes inliner to believe that all indirect reads and writes to/from pointers passed to function or function parameters will be optimized out. This is important to allow inlining of methods and SRAing out objects in C++ and devirtualizing calls, but for C code it is bit too optimistic. Partly this can be cured by IPA-SRA and Martin has WIP patch for clonning that contains more fine grained analysis of function body size specialized for given parameters. I however doubt they will catch all the cases we need for C++. Perhaps simply disabling the predicate for -Os or making it just weak hint (removing some percentage of estimated cost) is best way to go, I am just re-testing it on vangelis with size estimates ignoring it. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #6 from hubicka at gcc dot gnu dot org 2009-06-30 12:44 --- Created an attachment (id=18100) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18100action=view) Proposed patch The problem is that early inliner allows to increase code size estimate by inlining single function by up to 12 instructions. This is higher than on pretty-ipa branch still, since we are not that good on early optimizing yet and some C++ benchmarks (tramp/botan/boost) degrade when reduced to 7 as used by tramp3d. In tramp3d it is mostly caused by dead loops in constructors, and I hope that merging IPA-SRA and CD-DCE improvements will care this on all three benchmarks. At -O2 early inliner needs to be somewhat speculative since it don't know the function profiles yet. It however seems stupid to allow code size growth at -Os in general. This patch changes it reducing compress.o from 14k to 9k on i386. I guess I will need to give it full CSiBE run since it is question whether little speculative inlining won't result in better overall score. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #7 from hubicka at ucw dot cz 2009-06-30 12:46 --- Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852 The problem is that early inliner allows to increase code size estimate by inlining single function by up to 12 instructions. This is higher than on pretty-ipa branch still, since we are not that good on early optimizing yet and some C++ benchmarks (tramp/botan/boost) degrade when reduced to 7 as used by tramp3d. In tramp3d it is mostly caused by dead loops in constructors, and I ^^ pretty-ipa :) hope that merging IPA-SRA and CD-DCE improvements will care this on all three benchmarks. At -O2 early inliner needs to be somewhat speculative since it don't know the function profiles yet. It however seems stupid to allow code size growth at -Os in general. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #8 from steven at gcc dot gnu dot org 2009-06-30 13:14 --- Honza, I can take care of the CSiBE run if you want. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #9 from hubicka at gcc dot gnu dot org 2009-06-30 13:41 --- I can schedule it for nightly testing today, but if you have easier setup for CSiBE, it would help :) Thanks! Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #10 from steven at gcc dot gnu dot org 2009-06-30 19:55 --- I see no effect whatsoever of the patch for for CSiBE on arm-elf-unknown. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #11 from hubicka at ucw dot cz 2009-06-30 23:36 --- Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852 I see no effect whatsoever of the patch for for CSiBE on arm-elf-unknown. At -Os? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #12 from steven at gcc dot gnu dot org 2009-07-01 05:41 --- Yes, at -Os. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #5 from ramana at gcc dot gnu dot org 2009-06-19 23:14 --- The difference essentially is because all functions getting inlined into BZ2_Compress_Block with the newer heuristics. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #4 from ramana at gcc dot gnu dot org 2009-06-19 00:00 --- Confirmed that the problem exists. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-19 00:00:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-06-13 22:51 --- *** Bug 40437 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-06-13 23:07 --- Hmm, the measurements are most likely on x86 which might have slight differences when it comes to code size differences than arm. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|major |normal Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #3 from rearnsha at gcc dot gnu dot org 2009-06-13 23:10 --- For ARM -Os 114 files in CSiBE increase in size (total increase 21449 bytes) 20 files decrease in size (total decreases 1039 bytes); over all increase 20410 bytes) Worst single increase is from bzip2/compress (increase from 12495 to 19463 bytes). -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |major Keywords|missed-optimization | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
-- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Keywords||missed-optimization Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
