avr-llvm-devel

[avr-llvm-devel] New backend implementation

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

Hello everybody, I've been working lately in the AVR backend for LLVM by
myself until i've found this project. I'm not completely happy with the code
GCC produces so i decided to take on with this challenge. I think it would
be a good idea to join our efforts in this project, instead of duplicating
the work if we do it by separate.

My current code has the following status:

- It can build and emit AVR asm code for very basic C code.
- Produce code for all arithmetic and binary operators and for different
sizes wider than char (except division for larger types which will end being
a lib call).
- Basic support for shifts, currently only by a constant number. (We needed
here customized shifts because AVR only supports shifts by 1).
- Support for the multiplication instruction.
- Support for input function arguments and return values of any size.
- Code pass to fold two move instructions into a movw. (I dont like this as
a final solution since i prefer patching the DAG before codegen but it works
atm).
- Very basic support for function calls (I'm currently working into this).

My code looks very similar to the one in this project with some exceptions,
for example the instruction formats and instruction description. I've taken
a different approach on encoding instructions trying to pack instructions by
format like Reg,Reg or Reg, K, etc so we end up encoding them in a compact
form.

I've been running some tests and the code produced looks very promising,
LLVM produces more compact code than gcc without having written any single
optimization yet in my code. Of course there are cases that need tuning, but
I think optimizations should be left for a later stage in development until
things work decently. Although i couldnt resist on this last point, i've
reported some missed optimizations in the LLVM dev list, and filled them as
a bug report. One great thing about LLVM is that you get pretty fast support
and things get fixed much faster than for GCC where a bug report can be open
for 8 years.

Well let me know what you think and if we can merge our code.

Thanks

Re: [avr-llvm-devel] New backend implementation

[John M. <ato...@gm...>]

Hi,

I also think merging the projects would be good. Do you have a SourceForge
account? I can add you as a developer.
Are you developing off the trunk or a release? Our code is stale now, since
we haven't been keeping up with the trunk.
It sounds like your code is farther ahead in producing code.

--John


On Fri, Sep 24, 2010 at 6:06 AM, Borja Ferrer <bor...@gm...> wrote:

> Hello everybody, I've been working lately in the AVR backend for LLVM by
> myself until i've found this project. I'm not completely happy with the code
> GCC produces so i decided to take on with this challenge. I think it would
> be a good idea to join our efforts in this project, instead of duplicating
> the work if we do it by separate.
>
> My current code has the following status:
>
> - It can build and emit AVR asm code for very basic C code.
> - Produce code for all arithmetic and binary operators and for different
> sizes wider than char (except division for larger types which will end being
> a lib call).
> - Basic support for shifts, currently only by a constant number. (We needed
> here customized shifts because AVR only supports shifts by 1).
> - Support for the multiplication instruction.
> - Support for input function arguments and return values of any size.
> - Code pass to fold two move instructions into a movw. (I dont like this as
> a final solution since i prefer patching the DAG before codegen but it works
> atm).
> - Very basic support for function calls (I'm currently working into this).
>
> My code looks very similar to the one in this project with some exceptions,
> for example the instruction formats and instruction description. I've taken
> a different approach on encoding instructions trying to pack instructions by
> format like Reg,Reg or Reg, K, etc so we end up encoding them in a compact
> form.
>
> I've been running some tests and the code produced looks very promising,
> LLVM produces more compact code than gcc without having written any single
> optimization yet in my code. Of course there are cases that need tuning, but
> I think optimizations should be left for a later stage in development until
> things work decently. Although i couldnt resist on this last point, i've
> reported some missed optimizations in the LLVM dev list, and filled them as
> a bug report. One great thing about LLVM is that you get pretty fast support
> and things get fixed much faster than for GCC where a bug report can be open
> for 8 years.
>
> Well let me know what you think and if we can merge our code.
>
> Thanks
>
>
>
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America
> contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
> marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> avr-llvm-devel mailing list
> avr...@li...
> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>
>

Re: [avr-llvm-devel] New backend implementation

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

Hello John,
I havent created yet a SF account, but i could create one right now. I'm
currently developing for version 2.7, v2.8 is going to be released in a few
days so i will need to update my code for then because there has been some
changes in the interfaces. What i thought is to wait for the release, update
my code to make it compatible and then merge it into here.
Yes there are places that are a bit farther ahead, but others not. For
example, i've seen you've already added some code thinking on memory
addresses for IO and that stuff but i havent touched that at all yet.

As a side note, if it's possible to know, how many devs are involved in the
project and what is the time availability of them. Im asking this because i
noticed last commit was from march and you're the only one that is really
commiting code, so i want to know what is the status of the project and if
there are any plans.

Thanks.

2010/9/24 John Myers <ato...@gm...>

> Hi,
>
> I also think merging the projects would be good. Do you have a SourceForge
> account? I can add you as a developer.
> Are you developing off the trunk or a release? Our code is stale now, since
> we haven't been keeping up with the trunk.
> It sounds like your code is farther ahead in producing code.
>
> --John
>
>
> On Fri, Sep 24, 2010 at 6:06 AM, Borja Ferrer <bor...@gm...>wrote:
>
>> Hello everybody, I've been working lately in the AVR backend for LLVM by
>> myself until i've found this project. I'm not completely happy with the code
>> GCC produces so i decided to take on with this challenge. I think it would
>> be a good idea to join our efforts in this project, instead of duplicating
>> the work if we do it by separate.
>>
>> My current code has the following status:
>>
>> - It can build and emit AVR asm code for very basic C code.
>> - Produce code for all arithmetic and binary operators and for different
>> sizes wider than char (except division for larger types which will end being
>> a lib call).
>> - Basic support for shifts, currently only by a constant number. (We
>> needed here customized shifts because AVR only supports shifts by 1).
>> - Support for the multiplication instruction.
>> - Support for input function arguments and return values of any size.
>> - Code pass to fold two move instructions into a movw. (I dont like this
>> as a final solution since i prefer patching the DAG before codegen but it
>> works atm).
>> - Very basic support for function calls (I'm currently working into this).
>>
>> My code looks very similar to the one in this project with some
>> exceptions, for example the instruction formats and instruction description.
>> I've taken a different approach on encoding instructions trying to pack
>> instructions by format like Reg,Reg or Reg, K, etc so we end up encoding
>> them in a compact form.
>>
>> I've been running some tests and the code produced looks very promising,
>> LLVM produces more compact code than gcc without having written any single
>> optimization yet in my code. Of course there are cases that need tuning, but
>> I think optimizations should be left for a later stage in development until
>> things work decently. Although i couldnt resist on this last point, i've
>> reported some missed optimizations in the LLVM dev list, and filled them as
>> a bug report. One great thing about LLVM is that you get pretty fast support
>> and things get fixed much faster than for GCC where a bug report can be open
>> for 8 years.
>>
>> Well let me know what you think and if we can merge our code.
>>
>> Thanks
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Nokia and AT&T present the 2010 Calling All Innovators-North America
>> contest
>> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
>> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
>> marketing
>> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
>> http://p.sf.net/sfu/nokia-dev2dev
>> _______________________________________________
>> avr-llvm-devel mailing list
>> avr...@li...
>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>
>>
>

Re: [avr-llvm-devel] New backend implementation

[John M. <ato...@gm...>]

Hi,

There are only three devs right now. I'm not sure what the status is of the
others or how much time they have for the project.
I'm still interested in working on an avr lllvm port. Main line changes
broke our port not long after the 2.7 release. I got frustrated trying to
hunt down the problem and basically have been taking a break.

On Fri, Sep 24, 2010 at 10:01 AM, Borja Ferrer <bor...@gm...>wrote:

> Hello John,
> I havent created yet a SF account, but i could create one right now. I'm
> currently developing for version 2.7, v2.8 is going to be released in a few
> days so i will need to update my code for then because there has been some
> changes in the interfaces. What i thought is to wait for the release, update
> my code to make it compatible and then merge it into here.
> Yes there are places that are a bit farther ahead, but others not. For
> example, i've seen you've already added some code thinking on memory
> addresses for IO and that stuff but i havent touched that at all yet.
>
> As a side note, if it's possible to know, how many devs are involved in the
> project and what is the time availability of them. Im asking this because i
> noticed last commit was from march and you're the only one that is really
> commiting code, so i want to know what is the status of the project and if
> there are any plans.
>
> Thanks.
>
> 2010/9/24 John Myers <ato...@gm...>
>
> Hi,
>>
>> I also think merging the projects would be good. Do you have a SourceForge
>> account? I can add you as a developer.
>> Are you developing off the trunk or a release? Our code is stale now,
>> since we haven't been keeping up with the trunk.
>> It sounds like your code is farther ahead in producing code.
>>
>> --John
>>
>>
>> On Fri, Sep 24, 2010 at 6:06 AM, Borja Ferrer <bor...@gm...>wrote:
>>
>>> Hello everybody, I've been working lately in the AVR backend for LLVM by
>>> myself until i've found this project. I'm not completely happy with the code
>>> GCC produces so i decided to take on with this challenge. I think it would
>>> be a good idea to join our efforts in this project, instead of duplicating
>>> the work if we do it by separate.
>>>
>>> My current code has the following status:
>>>
>>> - It can build and emit AVR asm code for very basic C code.
>>> - Produce code for all arithmetic and binary operators and for different
>>> sizes wider than char (except division for larger types which will end being
>>> a lib call).
>>> - Basic support for shifts, currently only by a constant number. (We
>>> needed here customized shifts because AVR only supports shifts by 1).
>>> - Support for the multiplication instruction.
>>> - Support for input function arguments and return values of any size.
>>> - Code pass to fold two move instructions into a movw. (I dont like this
>>> as a final solution since i prefer patching the DAG before codegen but it
>>> works atm).
>>> - Very basic support for function calls (I'm currently working into
>>> this).
>>>
>>> My code looks very similar to the one in this project with some
>>> exceptions, for example the instruction formats and instruction description.
>>> I've taken a different approach on encoding instructions trying to pack
>>> instructions by format like Reg,Reg or Reg, K, etc so we end up encoding
>>> them in a compact form.
>>>
>>> I've been running some tests and the code produced looks very promising,
>>> LLVM produces more compact code than gcc without having written any single
>>> optimization yet in my code. Of course there are cases that need tuning, but
>>> I think optimizations should be left for a later stage in development until
>>> things work decently. Although i couldnt resist on this last point, i've
>>> reported some missed optimizations in the LLVM dev list, and filled them as
>>> a bug report. One great thing about LLVM is that you get pretty fast support
>>> and things get fixed much faster than for GCC where a bug report can be open
>>> for 8 years.
>>>
>>> Well let me know what you think and if we can merge our code.
>>>
>>> Thanks
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Nokia and AT&T present the 2010 Calling All Innovators-North America
>>> contest
>>> Create new apps & games for the Nokia N8 for consumers in  U.S. and
>>> Canada
>>> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
>>> marketing
>>> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
>>> http://p.sf.net/sfu/nokia-dev2dev
>>> _______________________________________________
>>> avr-llvm-devel mailing list
>>> avr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> avr-llvm-devel mailing list
> avr...@li...
> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>
>

Re: [avr-llvm-devel] New backend implementation

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

Ahh i see, thanks for the info. Well I hope that after the merge of my code
we can make it produce code again and that will probably make you get back
on track. The new LLVM version is going to introduce some big changes so
it'll break my code aswell but it shouldnt take too long to fix it.
I've just created an SF account, with name username "faluco".

Re: [avr-llvm-devel] New backend implementation

[Weddington, E. <Eri...@at...>]

Borja,

Welcome aboard!

I went ahead and added you to the project. Thanks for taking the time to work together on a common goal! :-)

You mentioned the new LLVM version will be introducing some big changes. I haven't been keeping up with the project as much recently. What kinds of big changes are being introduced that will cause problems?

Thanks,
Eric Weddington 

> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...] 
> Sent: Friday, September 24, 2010 12:49 PM
> To: avr...@li...
> Subject: Re: [avr-llvm-devel] New backend implementation
> 
> Ahh i see, thanks for the info. Well I hope that after the 
> merge of my code we can make it produce code again and that 
> will probably make you get back on track. The new LLVM 
> version is going to introduce some big changes so it'll break 
> my code aswell but it shouldnt take too long to fix it.
> I've just created an SF account, with name username "faluco".
> 
> 
> 
> 

Re: [avr-llvm-devel] New backend implementation

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

Hi Eric! Thanks for adding me to the project, i hope we can achieve good
results here to make a good AVR port.

About the changes, basically many interfaces have been improved, new
functions have been added and others removed. This will force us change
prototypes, remove deprecated functions and adapt the code to use the new
ones. Instruction descriptions have dropped support for isTwoAddress in
favour of constraints, the register description file needs some changes to
define subregs. The target register copying has been simplified to only use
copyPhysReg() so without this we cant move registers around. Design changes
with memory operands and stack slots, but i havent implemented this yet so
it's not a problem, we'll use directly use what 2.8 exposes.

2010/9/24 Weddington, Eric <Eri...@at...>

> Borja,
>
> Welcome aboard!
>
> I went ahead and added you to the project. Thanks for taking the time to
> work together on a common goal! :-)
>
> You mentioned the new LLVM version will be introducing some big changes. I
> haven't been keeping up with the project as much recently. What kinds of big
> changes are being introduced that will cause problems?
>
> Thanks,
> Eric Weddington
>
> > -----Original Message-----
> > From: Borja Ferrer [mailto:bor...@gm...]
> > Sent: Friday, September 24, 2010 12:49 PM
> > To: avr...@li...
> > Subject: Re: [avr-llvm-devel] New backend implementation
> >
> > Ahh i see, thanks for the info. Well I hope that after the
> > merge of my code we can make it produce code again and that
> > will probably make you get back on track. The new LLVM
> > version is going to introduce some big changes so it'll break
> > my code aswell but it shouldnt take too long to fix it.
> > I've just created an SF account, with name username "faluco".
> >
> >
> >
> >
>

Re: [avr-llvm-devel] New backend implementation

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

I've been taking a look at the code and noticed an important design issue
you took. It's about how registers are defined in the RegisterInfo.td file.
Defining register pairs is a good idea and in fact i did the same because it
simplifies many things, BUT, that brought some problems after i did more
testing. I noticed it when i tried to do a 16bit addition. LLVM will store
the operands in two different pairs but then it wont know how to perform the
addition because all add/sub instructions (ignoring ADIW) work with 8 bit
regs. What i supposed is that LLVM would be able to split the register pair
into individual regs perform the addition and then fuse them again into the
pair, but i was too optimisitc, it doesnt handle things that way. This issue
was the subject of my first email to the LLVM dev list.
So at the end i had to work only with 8 bit regs, that way LLVM is smart to
expand arithmetic operators of any size into a chain of add/addc
instructions in the case of the "+" operator. If you did the same assumption
i did then probably you would have faced this once you tested this case, but
if you did it for another purpose then we can discuss this further to see
how solve this problem.

Re: [avr-llvm-devel] New backend implementation

[Weddington, E. <Eri...@at...>]

Hi Borja,

I think that, at this point, if you feel that a certain design decision needs to be changed because it will get us farther in generating code, then you should feel free to make those changes as you deem necessary.

If there are any issues, I'm sure that we'll discuss them here on the list.

Eric Weddington 

> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...] 
> Sent: Sunday, September 26, 2010 11:01 AM
> To: avr...@li...
> Subject: Re: [avr-llvm-devel] New backend implementation
> 
> I've been taking a look at the code and noticed an important 
> design issue you took. It's about how registers are defined 
> in the RegisterInfo.td file. Defining register pairs is a 
> good idea and in fact i did the same because it simplifies 
> many things, BUT, that brought some problems after i did more 
> testing. I noticed it when i tried to do a 16bit addition. 
> LLVM will store the operands in two different pairs but then 
> it wont know how to perform the addition because all add/sub 
> instructions (ignoring ADIW) work with 8 bit regs. What i 
> supposed is that LLVM would be able to split the register 
> pair into individual regs perform the addition and then fuse 
> them again into the pair, but i was too optimisitc, it doesnt 
> handle things that way. This issue was the subject of my 
> first email to the LLVM dev list.
> So at the end i had to work only with 8 bit regs, that way 
> LLVM is smart to expand arithmetic operators of any size into 
> a chain of add/addc instructions in the case of the "+" 
> operator. If you did the same assumption i did then probably 
> you would have faced this once you tested this case, but if 
> you did it for another purpose then we can discuss this 
> further to see how solve this problem.
> 
> 
> 

Re: [avr-llvm-devel] New backend implementation

[John M. <ato...@gm...>]

Hi Borja,

We haven't got to the point of testing values greater then 8 bits. I thought
these things were suppose to be taken care if in AVRISelLowering.cpp? I
haven't really looked into this much but doesn't the legalize action of *
Expand* take care of this? If not what about the custom lowering?

 setOperationAction(ISD::ADD,              MVT::i16,   Expand);



On Sun, Sep 26, 2010 at 10:00 AM, Borja Ferrer <bor...@gm...>wrote:

> I've been taking a look at the code and noticed an important design issue
> you took. It's about how registers are defined in the RegisterInfo.td file.
> Defining register pairs is a good idea and in fact i did the same because it
> simplifies many things, BUT, that brought some problems after i did more
> testing. I noticed it when i tried to do a 16bit addition. LLVM will store
> the operands in two different pairs but then it wont know how to perform the
> addition because all add/sub instructions (ignoring ADIW) work with 8 bit
> regs. What i supposed is that LLVM would be able to split the register pair
> into individual regs perform the addition and then fuse them again into the
> pair, but i was too optimisitc, it doesnt handle things that way. This issue
> was the subject of my first email to the LLVM dev list.
> So at the end i had to work only with 8 bit regs, that way LLVM is smart to
> expand arithmetic operators of any size into a chain of add/addc
> instructions in the case of the "+" operator. If you did the same assumption
> i did then probably you would have faced this once you tested this case, but
> if you did it for another purpose then we can discuss this further to see
> how solve this problem.
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> avr-llvm-devel mailing list
> avr...@li...
> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>
>

Re: [avr-llvm-devel] New backend implementation

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

Eric, we could start with 8 bit regs for now and if we find that we can make
register pairs work we can then switch to use them.

John, sadly expansion wont work here because LLVM is not able to split the
pairs into single regs thus it cant find any 16 bit instructions. If we work
with 8 bit regs it will expand the code correctly, in fact, i didnt even add
the setOperandAction line, LLVM will do it automatically. Custom lowering is
a possible solution but im unsure now if it's the best.
First i have to say that i tried custom lowering the add instruction without
success because it involved splitting regs (i managed to do this) but i
failed at rebuilding the pairs because it involved using a 16bit OR
instruction which needed custom lowering and this also needed a 16 bit OR so
the story loops forever. I tried this the second day of development so by
that time i didnt have a very clear view yet of the compiler, dont know if
by now i would be able to do it.
You may want to read the discussion i had in the LLVM dev list in here:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-August/034203.html
search for the same subject in september aswell to read the whole thread.

I think we should stay away of customizing as much as possible and let LLVM
do the work, when i tried custom lowering i did it with DAG nodes and not by
inserting manually instructions with BuildMI() which is horrible in my
opinion because it takes away a lot of information to the codegen passes and
from what i've seen this is what GCC does, i took at look at GCC's .md file
and inside it you can find every single operation with custom assembly.
A test i did was a multiplication by a constant (something like short a = b
* 53, unsure now if this was the exact code), GCC would emit a mul and all
the add chain instructions being the high part of the constant 0 so all this
could have been saved, however LLVM noticed this and saved these mentioned
instructions, and i think this is caused because GCC's operations are all
manually written in the .md, i dont know too much about GCC so i may be
wrong though but the test im explaining is for real.
We could try customizing but only using DAG nodes, but notice this would
involve doing it for every single operation and size.

Currently the trouble i can think of using 8 bit regs is that we have to
tell LLVM to alloc 16 bit or wider data in odd:even pairs and how to bring
in the movws, but we can discuss this later on.

Re: [avr-llvm-devel] New backend implementation

[Weddington, E. <Eri...@at...>]

 

> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...] 
> Sent: Sunday, September 26, 2010 5:41 PM
> To: avr...@li...
> Subject: Re: [avr-llvm-devel] New backend implementation
> 
> I think we should stay away of customizing as much as 
> possible and let LLVM do the work,

Totally agreed. :-)

[avr-llvm-devel] Fwd: New backend implementation

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

I've just finished fixing the register calling convention. I had a huge TODO
in my code to handle passing chars in even registers and returning a char in
R24. I couldnt use the typical approach of using the Tablegen code to define
the calling convention because wide arguments are splitted into i8 pieces
making LLVM treat all args as chars so there was no easy way of knowing the
real size of each arg. I had to write it down in C++ code to check the real
argument size and allocate the regs using AVR's ABI spec.

A piece of code to show it:

typedef int t;
t foo(t a, t b, char c, int d)
{
    return a+b+d;
}

foo:                                    # @foo
    .ent foo
# BB#0:                                 # %entry
    add    r22, r18
    adc    r23, r19
    adc    r24, r20
    adc    r25, r21
    add    r22, r12
    adc    r23, r13
    adc    r24, r14
    adc    r25, r15
    ret

GCC generated this:

120:    cf 92           push    r12
 122:    df 92           push    r13
 124:    ef 92           push    r14
 126:    ff 92           push    r15
    return (a + b +d);
 128:    26 0f           add    r18, r22
 12a:    37 1f           adc    r19, r23
 12c:    48 1f           adc    r20, r24
 12e:    59 1f           adc    r21, r25
 130:    2c 0d           add    r18, r12
 132:    3d 1d           adc    r19, r13
 134:    4e 1d           adc    r20, r14
 136:    5f 1d           adc    r21, r15
 138:    b9 01           movw    r22, r18
 13a:    ca 01           movw    r24, r20
 13c:    ff 90           pop    r15
 13e:    ef 90           pop    r14
 140:    df 90           pop    r13
 142:    cf 90           pop    r12
 144:    08 95           ret

Forget the fact that our code isnt saving regs into the stack, that's
currently unimplemented, but notice those two movws are totally redundant,
pretty funny.
LLVM's site states that the new version will get released tomorrow, so i'll
start porting my code once that is done.

Re: [avr-llvm-devel] Fwd: New backend implementation

[Weddington, E. <Eri...@at...>]

Excellent! :-) 

Let us know how the new LLVM version is looking, and what will have to be done to get avr-llvm to match...

Thanks,
Eric Weddington

> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...] 
> Sent: Tuesday, September 28, 2010 2:56 PM
> To: avr...@li...
> Subject: [avr-llvm-devel] Fwd: New backend implementation
> 
> I've just finished fixing the register calling convention. I 
> had a huge TODO in my code to handle passing chars in even 
> registers and returning a char in R24. I couldnt use the 
> typical approach of using the Tablegen code to define the 
> calling convention because wide arguments are splitted into 
> i8 pieces making LLVM treat all args as chars so there was no 
> easy way of knowing the real size of each arg. I had to write 
> it down in C++ code to check the real argument size and 
> allocate the regs using AVR's ABI spec. 
> 
> 
> A piece of code to show it:
> 
> typedef int t;
> t foo(t a, t b, char c, int d)
> {
>     return a+b+d;
> }
> 
> foo:                                    # @foo
>     .ent foo
> # BB#0:                                 # %entry
>     add    r22, r18
>     adc    r23, r19
>     adc    r24, r20
>     adc    r25, r21
>     add    r22, r12
>     adc    r23, r13
>     adc    r24, r14
>     adc    r25, r15
>     ret
> 
> GCC generated this:
> 
> 120:    cf 92           push    r12
>  122:    df 92           push    r13
>  124:    ef 92           push    r14
>  126:    ff 92           push    r15
>     return (a + b +d);
>  128:    26 0f           add    r18, r22
>  12a:    37 1f           adc    r19, r23
>  12c:    48 1f           adc    r20, r24
>  12e:    59 1f           adc    r21, r25
>  130:    2c 0d           add    r18, r12
>  132:    3d 1d           adc    r19, r13
>  134:    4e 1d           adc    r20, r14
>  136:    5f 1d           adc    r21, r15
>  138:    b9 01           movw    r22, r18
>  13a:    ca 01           movw    r24, r20
>  13c:    ff 90           pop    r15
>  13e:    ef 90           pop    r14
>  140:    df 90           pop    r13
>  142:    cf 90           pop    r12
>  144:    08 95           ret
> 
> Forget the fact that our code isnt saving regs into the 
> stack, that's currently unimplemented, but notice those two 
> movws are totally redundant, pretty funny.
> LLVM's site states that the new version will get released 
> tomorrow, so i'll start porting my code once that is done.
> 
> 
> 

Re: [avr-llvm-devel] Fwd: New backend implementation

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

LLVM's new version hasnt't been released yet, hope it doesnt get delayed too
much. In the meantime i've been cleaning a bit my code to make it ready to
be updated.

Re: [avr-llvm-devel] Fwd: New backend implementation

[John M. <ato...@gm...>]

You can also work off of  */llvm/branches/release_28*. No major changes to
the function prototypes and class interfaces should happen at this point.

On Sat, Oct 2, 2010 at 4:34 PM, Borja Ferrer <bor...@gm...> wrote:

> LLVM's new version hasnt't been released yet, hope it doesnt get delayed
> too much. In the meantime i've been cleaning a bit my code to make it ready
> to be updated.
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> avr-llvm-devel mailing list
> avr...@li...
> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>
>

Re: [avr-llvm-devel] Fwd: New backend implementation

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

Yes, but im unsure if my 2.7 gcc-llvm binaries will work with this new
version.

2010/10/3 John Myers <ato...@gm...>

> You can also work off of  */llvm/branches/release_28*. No major changes to
> the function prototypes and class interfaces should happen at this point.
>
> On Sat, Oct 2, 2010 at 4:34 PM, Borja Ferrer <bor...@gm...>wrote:
>
>> LLVM's new version hasnt't been released yet, hope it doesnt get delayed
>> too much. In the meantime i've been cleaning a bit my code to make it ready
>> to be updated.
>>
>>
>> ------------------------------------------------------------------------------
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing.
>> http://p.sf.net/sfu/novell-sfdev2dev
>> _______________________________________________
>> avr-llvm-devel mailing list
>> avr...@li...
>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>
>>
>