[Bug target/54888] GCC with -Os is faster than -O3 on some AVR code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54888 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC|gjl at gcc dot gnu.org | Resolution||INVALID --- Comment #6 from Georg-Johann Lay gjl at gcc dot gnu.org 2013-02-02 14:21:27 UTC --- Closed as invalid. No answer and no valid test case for over 3 months now.
[Bug target/54888] GCC with -Os is faster than -O3 on some AVR code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54888 --- Comment #3 from mojo at world3 dot net 2012-10-22 12:40:57 UTC --- (In reply to comment #2) And I actually don't understand teh issue: Optimizing for size does not require to produce slow code. The code may run fast. -O3 is supposed to produce the fastest possible code, but it doesn't. -Os is faster. At the very least the two should be equal. In other words -O3 is broken.
[Bug target/54888] GCC with -Os is faster than -O3 on some AVR code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54888 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2012-10-22 12:56:23 UTC --- (In reply to comment #3) (In reply to comment #2) And I actually don't understand teh issue: Optimizing for size does not require to produce slow code. The code may run fast. -O3 is supposed to produce the fastest possible code, but it doesn't. -Os is faster. At the very least the two should be equal. Supposed to? Where in the documentation is that specified? I remember a sentence that -O3 enables optimization that might not always be profitable (but that sentence seems to be gone from latest docs). In other words -O3 is broken. It's behavior is certainly undesirable, but broken? For certain targets -Os might be a win because that's what it is tuned for or icache behavior is simply more important than anything else.
[Bug target/54888] GCC with -Os is faster than -O3 on some AVR code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54888 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added CC||gjl at gcc dot gnu.org --- Comment #5 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-10-22 20:10:44 UTC --- As a start, you could try to enable us to reproduce your problem. First of all, it is clear that we don't have your hardware (oscilloscope) to measure things and even if, it is very unlikely someone will start research to find out exactly were you lost the ticks. Second, notice that it is ulikely anybody is inclined to pick up buch of code you dumped above. It's 3800 lines and around 30 functions. And it fails to compile. Maybe you can be more descriptive and point out what /exactly/ goes wrong and work out a small example and limit to a critical spot or function and throw away unneeded stuff. Third, please notice that 4.3 is no more supported since several years now. Please supply code that compiles with a supported version of the compiler which implies at least 4.7 (because you use -mmcu=atxmega128d3). Fourth, you use inline assembler that is not correct because of missing memory barrier and might show malfunction in corner cases. Thus, you may want to fix at least 3. and 4. and rerun your benchmarks to see if the problem still exists. Very likely, that is not the case.
[Bug target/54888] GCC with -Os is faster than -O3 on some AVR code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54888 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Target||avr Priority|P3 |P4 Status|UNCONFIRMED |WAITING Last reconfirmed||2012-10-21 Component|c |target Ever Confirmed|0 |1 --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-10-21 20:40:45 UTC --- atxmega128d3 is not supported by avr-gcc, neither in 4.3 nor in 4.4 nor 4.5 nor 4.6. Please report to the respective bug tracker, obviously some private toolchain port. Compiling with a current compiler that supports ATxmega128D3 (4.7 or newer) stops compilation with errors. And I actually don't understand teh issue: Optimizing for size does not require to produce slow code. The code may run fast. If your program relies on slow executable code, the program is incorrect.
