Re: [avr-llvm-devel] Status update

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

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

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

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.