Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

[Weddington, Eric]

> -----Original Message-----
> From: Georg-Johann Lay [mailto:address@hidden
> Sent: Friday, January 13, 2012 2:13 AM
> To: Weddington, Eric
> Cc: Joerg Wunsch; address@hidden
> 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