Re: [avr-llvm-devel] Status update

[Weddington, E. <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.

> 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.


> 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.

 
> 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.


> 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.


> 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?

HTH,
Eric Weddington