[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359 --- Comment #15 from Fredrik Hederstierna --- Created attachment 38185 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38185=edit tok.c I took another example for CSiBE and stripped it down. I'm

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359 --- Comment #14 from kugan at gcc dot gnu.org --- (In reply to Jeffrey A. Law from comment #13) > The change to the assignment of p_22 is made by forwprop1. > > It does create a situation where p_2 is live outside the loop and hides the > CSE

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359 --- Comment #13 from Jeffrey A. Law --- The change to the assignment of p_22 is made by forwprop1. It does create a situation where p_2 is live outside the loop and hides the CSE opportunity, which may be the cause of the more significant

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359 --- Comment #12 from kugan at gcc dot gnu.org --- However, diff of cfgexand is significantly different: ;; Full RTL generated for this function: ;; 32: NOTE_INSN_DELETED - 38: NOTE_INSN_BASIC_BLOCK 2 + 39: NOTE_INSN_BASIC_BLOCK 2

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359 --- Comment #11 from kugan at gcc dot gnu.org --- Optimized gimple diff between 5.3 and trunk is : -;; Function inttostr (inttostr, funcdef_no=0, decl_uid=5268, cgraph_uid=0, symbol_order=0) +;; Function inttostr (inttostr, funcdef_no=0,

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359 --- Comment #10 from kugan at gcc dot gnu.org --- I am looking into it. -mcpu=arm966e-s does not uses the TARGET_NEW_GENERIC_COSTS. i.e, the rtx costs setup by the back-end might not be optimal.

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359 --- Comment #9 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #5) > CCing authors of the other commits. That said, complaining about size > regressions generally should be only if it (significantly) increases sizes > of

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359 --- Comment #8 from Jakub Jelinek --- All I wanted to say is that it is to be expected that on some code a newer GCC version ends up needing one or two more instructions, even at -Os, and what matters is not the size of a single function, but

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359 --- Comment #7 from Jeffrey A. Law --- I would suggest that you definitely keep reporting these things and extracting examples from csibe or other benchmarks to show the codesize increases. While some folks will prioritize performance, it

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359 --- Comment #6 from Fredrik Hederstierna --- Thanks for your analysis on this. One comment on this 'complaint', it's not only about size - in my example the compiler uses 2 more regs push and pop, and

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org,

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359 Ramana Radhakrishnan changed: What|Removed |Added Target|arm-none-eabi |arm-none-eabi,

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #3

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359 --- Comment #2 from Andrew Pinski --- (In reply to Richard Biener from comment #1) > My #1 bet would be FSM threading. I doubt it as if I read the asm differences correctly, GCC 6 just no longer does store with post increment and that causes

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359 Richard Biener changed: What|Removed |Added Keywords||missed-optimization