> -----Original Message----- > From: Georg-Johann Lay [mailto:a...@gjlay.de] > Sent: Friday, January 13, 2012 2:13 AM > To: Weddington, Eric > Cc: Joerg Wunsch; avr-gcc-list@nongnu.org > Subject: Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are > incorrect > > avr-libc can stay as is, I will work out a solution that won't require any > avr-libc changes (under the assumption that avr-libc if fine with being > non-standard compliant with respect to double).
Well, I can't speak for the other admins of avr-libc, but I'd like to see avr-libc have standard functions for double, even if we have other functions that do the same for float. Philosophically, I'd like to give the user the choice of what functions to use, even if those functions (with the double type) are huge and pretty much inefficient. > >> The backend is too late to fix it. It can be done but it rather > clutters > >> up backend with ugly code like for http://gcc.gnu.org/PR29560 > >> Similar problems arise in http://gcc.gnu.org/PR18065 > >> > >> The front end says: "I must comply to the standards" > >> The middle ends crunch the code and don't have the big picture. > >> The back end is left with the bad code and hacks on it but cannot > >> really fix it because it's too late. > >> > >> So you need someone to dive into the tree optimization passes and does > >> the changes for our irrelevant architecture there. > > > > Rats. > > > > Stupid question, because I'm not a compiler expert: Could any of this be > > done with peephole (or in gcc parlance peephole2) optimizations? > > peep2 is not will suited for that. Sometimes you don't have the relevant > information and in other cases cutting down the operation does not help: > what > you'd actually need is also to optimize the code that lead to the > situation or > that uses the cut-down result. So you also want to optimize code around > the > promote-spot. You always need certain amount of context to properly > optimize. > Moreover, registers already have been allocated in peep2, so if you need > less > registers you cannot roll back. Thanks for the explanation. Agreed, that it's not an ideal situation. But we really need to have a way to generate the most efficient code for our target. Even if we have to muck around in tree optimization passes as you suggest. _IF_ (and it's a big *if) for some reason that we can't make the needed changes in the guts of GCC, whether it's because of technical issues, or the GCC project will not agree to accept our changes, then our only alternative is to try to do it better with LLVM. http://sourceforge.net/projects/avr-llvm/ Eric _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
