On Sat, 18 Apr 2009, Sean D'Epagnier wrote:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=77805
This is cool, though I largely agree with the message in this thread which
says that most of the time, poor avr-gcc output should simply be filed as
bugs in the AVR backend.
The superoptimizer must be extremely careful in rewriting loads and
stores. Probably the best policy would be to never duplicate or eliminate
a memory operation. The reason is that volatile qualifiers have been lost
by the time the compiler finishes.
Sean the limit case of what you are working on is something like Diablo,
you should read some of their papers:
http://diablo.elis.ugent.be/publications
It is an excellent tool.
Many benefits of something like Diablo come from optimizing the
application and all of its libraries together. Someone should figure out
how to get this kind of benefit for AVR. I have spent a bunch of time
looking at avr-gcc output over the past couple weeks and have seen many
cases where better code could have been generated by perforing IPO on the
application + libraries. In many cases simply propagating constants into
avr-libc would get most of the benefit.
John Regehr
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
