[Bug target/70676] suboptimal code generation on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70676 Eric Gallager changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED CC||egallager at gcc dot gnu.org --- Comment #11 from Eric Gallager --- (In reply to Georg-Johann Lay from comment #10) > (In reply to night_ghost from comment #9) > > Really this is a best way to fix bugs! Just ignore them - like an ostrich, > > hiding head in the sand. > > I just requested some information as outlines in the bug reporting > instructions. > > That you have the information available does not mean I can guess it by > magic, and guessing has turned out to be extremely ineffective, time > consuming and often enough it comes up with guesses that completely diverge > from a bug reportes intention. > > At some point I just stopped digging into your stuff and requested some more > information. > > Yust the fact that you are not able or not willing to provide that > information does not mean it's nor required. So, closing again, since the requested information still hasn't been supplied yet.
[Bug target/70676] suboptimal code generation on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70676 Georg-Johann Lay changed: What|Removed |Added Status|REOPENED|WAITING --- Comment #10 from Georg-Johann Lay --- (In reply to night_ghost from comment #9) > Really this is a best way to fix bugs! Just ignore them - like an ostrich, > hiding head in the sand. I just requested some information as outlines in the bug reporting instructions. That you have the information available does not mean I can guess it by magic, and guessing has turned out to be extremely ineffective, time consuming and often enough it comes up with guesses that completely diverge from a bug reportes intention. At some point I just stopped digging into your stuff and requested some more information. Yust the fact that you are not able or not willing to provide that information does not mean it's nor required.
[Bug target/70676] suboptimal code generation on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70676 night_ghost at ykoctpa dot ru changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #9 from night_ghost at ykoctpa dot ru --- Really this is a best way to fix bugs! Just ignore them - like an ostrich, hiding head in the sand.
[Bug target/70676] suboptimal code generation on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70676 Georg-Johann Lay changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #8 from Georg-Johann Lay --- No reply in more than 6 months, closing...
[Bug target/70676] suboptimal code generation on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70676 --- Comment #7 from Georg-Johann Lay --- Sorry, but guessing around has proben to be extremely unefficient and error prone, in particular if the information is available on the other end of the wire. If -mrelax leads to wrong code, then you shoulr report this to the Binutils project, because avr-gcc just passes through -mrelax to Binutils.
[Bug target/70676] suboptimal code generation on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70676 --- Comment #6 from night_ghost at ykoctpa dot ru --- I reported not one case but suboptimal behavior while optimizing size - GCC optimization of sibling calls increases size of binary. There are a lot of such places in this code. And GCC never replaces call-ret sequence to jmp, relying on linkers optimizing by -relax. But including -relax flag often spoils the project to complete failure.
[Bug target/70676] suboptimal code generation on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70676 --- Comment #5 from Georg-Johann Lay --- Whould you please mention to what module you are referring? Spi.ii?
[Bug target/70676] suboptimal code generation on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70676 --- Comment #4 from night_ghost at ykoctpa dot ru --- Created attachment 38551 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38551=edit testcase in attachment without -no-optimize-sibling-call reported bug can be found in MinimOsd_Extra.s on lines 2424, 3249 and so on - all POP's of epilogue can be done before comparison. If GCC can't move up epilogue to that place then such optimization is not suitable for -Os because it means "in size at the expense of the rest", especially on embedded, where task - to shove an elephant into a beaker (I can not better translate Russian proverb "Впихнуть невпихнуемое")
[Bug target/70676] suboptimal code generation on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70676 --- Comment #3 from Georg-Johann Lay --- You can follow the bug reporting instructions an provide the preprocessed code and the compiler output as described in https://gcc.gnu.org/bugs/#need Just add -v -save-temps to the compiler's command line options, re-build the project, and supply the output of the compiler and the generated *.i file (in case of C) resp. *.ii file (in case of C++).
[Bug target/70676] suboptimal code generation on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70676
--- Comment #2 from night_ghost at ykoctpa dot ru ---
*** testcase for call+ret: (all code from
https://github.com/night-ghost/minimosd-extra/tree/master/MinimOsd_Extra),
compile with -fno-optimize-sibling-calls
#include
class SPI
{
public:
SPI(void);
static byte transfer(byte);
};
SPI::SPI()
{
#define SCK_PIN 13
#define MISO_PIN 12
#define MOSI_PIN 11
// initialize the SPI pins
pinMode(SCK_PIN, OUTPUT);
pinMode(MOSI_PIN, OUTPUT);
pinMode(MISO_PIN, INPUT);
}
byte SPI::transfer(byte value){
SPDR = value;
while (!(SPSR & (1<Provided you use -mrelax (or link with -Wl,--relax), the linker tries to
>replace [R]CALL+RET by [R]JMP instruction
Thanks for good key, it saves 700bytes of code (from 30642 to 29942)
[Bug target/70676] suboptimal code generation on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70676 Georg-Johann Lay changed: What|Removed |Added Keywords||missed-optimization Target||avr Priority|P3 |P5 Status|UNCONFIRMED |WAITING Last reconfirmed||2016-05-21 CC||gjl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Georg-Johann Lay --- You missed to add a test case, cf. https://gcc.gnu.org/bugs/#need > Can GCC in -Os really optimize only size and rollback optimizations No, GCC usually won't "rollback" optimizations, and it won't perform speculative optimizations. There are cases where avr-gcc does not optimize sibling calls. Provided you use -mrelax (or link with -Wl,--relax), the linker tries to replace [R]CALL+RET by [R]JMP instruction. If there is a label at the }, i.e. between the CALL and the RET, no optimization is possible.
