Re: [avr-llvm-devel] Status update

[Borja F. <bor...@gm...>]

2011/5/20 Weddington, Eric <Eri...@at...>

>
>
> > -----Original Message-----
> > From: Borja Ferrer [mailto:bor...@gm...]
> > Sent: Thursday, May 19, 2011 3:54 PM
> > To: Weddington, Eric
> > Cc: avr...@li...
> > Subject: Re: [avr-llvm-devel] Status update
> >
> > Hello Eric,
> >
> > It could be possible to implement both ABIs, but right now i'm unsure
> > about how much work that would take and its difficulty. I personally
> > haven't really thought about a new ABI standard since this is something
> > that needs a deep thought and some analysis, indeed some opinions from
> > atmel would be very helpful.
>
> And I'm happy to help out in this area. Agreed, that it will take quite a
> bit of thinking *and* tinkering.
>

Ok then, I guess the best thing to do would be sticking to the gcc ABI until
we get a functional compiler, and then patch it with the new ABI to support
both. However, we could open a new discussion about the new ABI in another
thread during the meantime since this is something that will take some time
to arrive to some consensus and it won't get forgotten.


>
> > I faced these issues while taking a look at
> > how gcc and iar manipulated frames and the stack during the past days,
> and
> > there is where i noticed the huge diference in performance and code size.
> > I really havent taken a look at the IAR ABI standard,
>
> And something to keep in mind is that IAR uses *2* stacks, one for local
> variables and one for function return addresses to quickly pop out of a
> function.
>

Very interesting, I didnt know about this, i guess i'll have to take a look
at the IAR specs to see what it does. Is it even possible to beat IAR's ABI
since you have a better understanding of it?



>
>
> > but i've been
> > comparing code produced (mainly stressing register allocation with math
> > calculations with double precision types) by IAR and llvm and the global
> > difference in code size is only related to the ABI. What do i mean? well,
> > that if we ignore prologue, epilogue and stack manipulation stuff which
> is
> > pure ABI specific, llvm produces shorter code and requires less frame
> > memory, otherwise they perform quite equally on average because of the
> > overhead the gcc ABI has.
>
> Well this is *very* good news then! This means that it is theoretically
> possible to do even better than IAR, if only we design an appropriate ABI. I
> do feel that an alternative, better ABI can be developed. It's just a matter
> of some effort and time.
>

For what i've tested so far which is very "movw" and "call" intensive since
all double operations are function calls, when we get down to lots of arith
operations and stuff like that we'll have to get our hands dirty to combine
operations like IAR does, this is where IAR outperforms gcc. For now im not
focusing at all in optimizations since i want to be able to have a
functional compiler first, but the code produced is quite decent, so when
optimizations get introduced the code quality upgrade should be huge.



>
>
> > My biggest concern here supposing the ABI is changed in the future is the
> > custom assembly written by users, that would mean a huge change for them
> > since they would get forced to rewrite their code and i'm uncertain about
> > their reactions.
>
> I'm a little less concerned, and that's mainly to do with having been in
> this area for several years.
>
> Yes, any ABI change could induce a cost to the end user. However:
>
> - Any cost to the end user would have to be offset by the benefits
> involved. If we can show that avr-llvm can produce smaller code than the
> best commercial AVR compiler on the market, then the benefits far outweigh
> the costs.
>
> - The actual costs would be minimal. Most users write their code in C, or
> even C++. There are very few actual projects out there that include some
> form of assembly. Of those that do, most would use some form of inline
> assembly. There are less users that even have assembly-only functions within
> a larger C project where they have to adjust their prologues and epilogues
> due to an ABI change. And even then, there are usually a very small finite
> number of assembly functions. Even rarer is the true all assembly-only
> application. So, I think, in reality the impact of changing the ABI on user
> applications is extremely small and therefore not as relevant. The biggest
> impact would be on avr-libc.
>

I absolutely agree with you on that. Btw, big words there mentioning beating
the best comercial compiler on the market xD During the years i've been
coding I've never cared about backwards compatibility, when i received the
question about breaking some library interface or binary format my reply was
always go on for it. But this is the first time I think im caring because we
have to first adapt to the users, not the other way round as it always
happened to me.



> > The libc transition would be easier to do since many
> > assembly functions use registers defined in macros instead of using their
> > real names, so that would make things simpler.
>
> Avr-libc would have to be audited to make sure that truly is the case. But
> it's just "work". Not that hard, but a little time-consuming. But I think
> very doable.
>
> > But again, would you then
> > have two different libc's or you would deprecate the one using the old
> > abi? it's not that obvious.
>
> Well, ideally, it might be best to make sure that we could compile avr-libc
> with either ABI while we do a transition. But I think we're putting the cart
> before the horse. I'm willing to look into what that will take with avr-libc
> once we have a working avr-llvm with promise of supplanting avr-gcc with
> better code generation.
>
> Indeed, no need to advance on these things until we get working compiler.



>
> > In relation to the development, right now I'm stuck reserving the Y reg
> > when stack frames are needed so it doesnt get used by anything else. To
> > know if all regs get spilled so stack memory is allocated thus needing Y
> > to access stack memory you need to run the reg allocator but that will
> use
> > the Y reg for other purposes if it's available, so it's like needing to
> > know the future to resolve something in the present. LLVM handles stack
> > stuff in a later stage, after register allocation is done, and there is
> > where you know if you really need to reserve Y to access the stack or you
> > can use it for other things.
>
> It sounds like you've got a handle on what needs to be done. Is there a way
> to run the register allocator more than once? Run it with Y available to see
> if the result works, if not, then reserve Y and run the allocator again
> without Y available?
>
> That's what i've thought as well, i'm going to ask the the llvm dev list to
see if it's possible to do it. 2 weeks ago approx the llvm devs released a
new reg alloc that is the one on by default that reduces frame size by using
more register swapping, i've seen some improvements in little tests i run,
so at least it's good to know that they're very active in improving codegen
quality.


> HTH,
> Eric Weddington
>