avr-llvm-devel — Developers mailing list.

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

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

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

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

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,

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

[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] llvm-avr with Ada front-end

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

Hi Rolf,

The AVR port of LLVM is nowhere near being able to generate code. We'll have to stick with AVR-Ada for now.

Eric Weddington 

> -----Original Message-----
> From: Rolf Ebert [mailto:rol...@gm...] 
> Sent: Saturday, June 26, 2010 9:26 AM
> To: avr...@li...
> Subject: [avr-llvm-devel] llvm-avr with Ada front-end
> 
> Hi,
> 
> my goal is to build an Ada compiler for AVR targets.
> 
> Do you have some hints or recommendations on how to proceed? I found 
> some (old) instructions on how to build Ada support for llvm 
> and I found 
> a message on this mailing list from last November about 
> adding the AVR 
> part to llvm.
> 
> I've got some experience in building compilers (see AVR-Ada 
> project at 
> SF) but did not try llvm yet.
> 
>     Rolf
> 
> --------------------------------------------------------------
> ----------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> avr-llvm-devel mailing list
> avr...@li...
> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
> 

[avr-llvm-devel] llvm-avr with Ada front-end

[Rolf E. <rol...@gm...>]

Hi,

my goal is to build an Ada compiler for AVR targets.

Do you have some hints or recommendations on how to proceed? I found 
some (old) instructions on how to build Ada support for llvm and I found 
a message on this mailing list from last November about adding the AVR 
part to llvm.

I've got some experience in building compilers (see AVR-Ada project at 
SF) but did not try llvm yet.

    Rolf

Re: [avr-llvm-devel] [avr-llvm-commits] SF.net SVN: avr-llvm:[59] llvm/trunk

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

 

> -----Original Message-----
> From: joe...@us... 
> [mailto:joe...@us...] 
> Sent: Wednesday, December 09, 2009 1:13 PM
> To: avr...@li...
> Subject: [avr-llvm-commits] SF.net SVN: avr-llvm:[59] llvm/trunk
> 
> Revision: 59
>           
> http://avr-llvm.svn.sourceforge.net/avr-llvm/?rev=59&view=rev
> Author:   joeezapster
> Date:     2009-12-09 20:12:50 +0000 (Wed, 09 Dec 2009)
> 
> Log Message:
> -----------
> - added support for i8 arguments
> 

Great! :-) Thanks for doing this!

Eric

Re: [avr-llvm-devel] Windows build

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

LOL, I must have had a bad build after I added that because original I
didn't see any changes.

On Wed, Dec 9, 2009 at 7:08 AM, Josef Eisl <za...@za...> wrote:

> John Myers wrote:
> >     What's up with the redundant mov? Or will future optimization take
> >     care of removing this?
> >
> >     >         ret
> >     >         .size   func, .-func
> >     >
> >     >
> >
> > The redudant mov is gone now. So it looks like whatever they changed  in
> > the LLVM trunk fixed it.
>
> Nope. You fixed it in r53 ;)! The isMoveInstr() allows llvm to detect
> redundant MOVs.
> BTW: great work!
>
> Josef
>

Re: [avr-llvm-devel] Windows build

[Josef E. <za...@za...>]

John Myers wrote:
>     What's up with the redundant mov? Or will future optimization take
>     care of removing this?
> 
>     >         ret
>     >         .size   func, .-func
>     >
>     >
> 
> The redudant mov is gone now. So it looks like whatever they changed  in
> the LLVM trunk fixed it.

Nope. You fixed it in r53 ;)! The isMoveInstr() allows llvm to detect
redundant MOVs.
BTW: great work!

Josef

Re: [avr-llvm-devel] Windows build

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

 

> -----Original Message-----
> From: John Myers [mailto:ato...@gm...] 
> Sent: Tuesday, December 08, 2009 8:30 PM
> To: Weddington, Eric
> Cc: avr...@li...
> Subject: Re: [avr-llvm-devel] Windows build
> 
> 
>  
> I'll try to find were the .align directive is printed to 
> remove it. Will it mess things up if it's there?
>  

It might. I'm not sure if .align 16 is correct for the AVR target. Thanks for looking into this.

AFAIK, the AVR default linker script for GNU ld take care of aligning the functions on a word (16-bit) boundary.

Re: [avr-llvm-devel] Windows build

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

On Tue, Dec 8, 2009 at 7:04 PM, Weddington, Eric
<Eri...@at...>wrote:

>
>
> > -----Original Message-----
> > From: John Myers [mailto:ato...@gm...]
> > Sent: Tuesday, December 08, 2009 6:46 PM
> > To: Weddington, Eric
> > Cc: avr...@li...
> > Subject: Re: [avr-llvm-devel] Windows build
> >
> >
> >
> > The redudant mov is gone now. So it looks like whatever they
> > changed  in the LLVM trunk fixed it.
>
> That's great!
>
> Question: Is the assembler output of llvm supposed to closely match the
> assembler output of avr-gcc? Is that what we're aiming for?
>

Yeah, it's suppose to be an assembly printer for gas / avr-gcc. Some targets
actually produce multiple asm types for different assembler brands.

>
> > C:\_projects_\build_llvm\bin\Debug>llc.exe -O0 -o -
> > -filetype=asm -mcpu=atmega128 reti8.ll
> >         .file   "reti8.ll"
> >
> >         .text
> >         .align  16
> >         .global func
> >         .type   func,@function
> > func:
> > # BB#0:
> >         ldi r24, #1
> >         ret
> >         .size   func, .-func
>
> If so, then we need to drop the .align directive above. This is the
> equivalent from avr-gcc:
>

I'll try to find were the .align directive is printed to remove it. Will it
mess things up if it's there?


>
>        .file   "test.c"
> __SREG__ = 0x3f
> __SP_H__ = 0x3e
> __SP_L__ = 0x3d
> __CCP__  = 0x34
> __tmp_reg__ = 0
> __zero_reg__ = 1
>        .text
> .global func
>        .type   func, @function
> func:
> /* prologue: function */
> /* frame size = 0 */
>        ldi r24,lo8(1)
> /* epilogue start */
>        ret
>        .size   func, .-func
>

Re: [avr-llvm-devel] Windows build

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

 

> -----Original Message-----
> From: John Myers [mailto:ato...@gm...] 
> Sent: Tuesday, December 08, 2009 6:46 PM
> To: Weddington, Eric
> Cc: avr...@li...
> Subject: Re: [avr-llvm-devel] Windows build
> 
> 
> 
> The redudant mov is gone now. So it looks like whatever they 
> changed  in the LLVM trunk fixed it.

That's great!

Question: Is the assembler output of llvm supposed to closely match the assembler output of avr-gcc? Is that what we're aiming for?
  
> C:\_projects_\build_llvm\bin\Debug>llc.exe -O0 -o - 
> -filetype=asm -mcpu=atmega128 reti8.ll
>         .file   "reti8.ll"
> 
>         .text
>         .align  16
>         .global func
>         .type   func,@function
> func:
> # BB#0:
>         ldi r24, #1
>         ret
>         .size   func, .-func

If so, then we need to drop the .align directive above. This is the equivalent from avr-gcc:

	.file	"test.c"
__SREG__ = 0x3f
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__CCP__  = 0x34
__tmp_reg__ = 0
__zero_reg__ = 1
	.text
.global	func
	.type	func, @function
func:
/* prologue: function */
/* frame size = 0 */
	ldi r24,lo8(1)
/* epilogue start */
	ret
	.size	func, .-func

Re: [avr-llvm-devel] Windows build

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

On Fri, Dec 4, 2009 at 10:23 PM, Weddington, Eric <Eri...@at...
> wrote:
>         .type   func,@function
> func:
> # BB#0:
>         ldi r24, #1
>         mov r24, r24

What's up with the redundant mov? Or will future optimization take care of
> removing this?
>
> >         ret
> >         .size   func, .-func
> >
> >
>
The redudant mov is gone now. So it looks like whatever they changed  in the
LLVM trunk fixed it.

C:\_projects_\build_llvm\bin\Debug>llc --version
Low Level Virtual Machine (http://llvm.org/):
  llvm version 2.7svn
  DEBUG build with assertions.
  Built Dec  7 2009 (21:57:15).
  Host: i686-pc-win32
  Host CPU: (unknown)
  Registered Targets:
    avr - AVR [experimental]
C:\_projects_\build_llvm\bin\Debug>llc.exe -O0 -o - -filetype=asm
-mcpu=atmega128 reti8.ll
        .file   "reti8.ll"

        .text
        .align  16
        .global func
        .type   func,@function
func:
# BB#0:
        ldi r24, #1
        ret
        .size   func, .-func

Re: [avr-llvm-devel] Windows build

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

On Fri, Dec 4, 2009 at 10:23 PM, Weddington, Eric <Eri...@at...
> wrote:

>
>
> > -----Original Message-----
> > From: John Myers [mailto:ato...@gm...]
> > Sent: Friday, December 04, 2009 10:18 PM
> > To: avr...@li...
> > Subject: [avr-llvm-devel] Windows build
> >
> >
> > I had a pain free build using Visual Studio C++ 2008 express
> > edition and CMake on Windows XP.
>
> Congratulations!
>
> > C:\_projects_\build_llvm\bin\Debug>llc.exe -O0 -filetype=asm
> > -mcpu=atmega128 reti8.ll -o -
> >         .file   "reti8.ll"
> >
> >         .text
> >         .align  16
> >         .globl  func
>
> Can we change the directive to be the full spelling?: .global
>
>
Yeah, that's an easy change (it's in AsmPrinter\AVRAsmPrinter.cpp).


> >         .type   func,@function
> > func:
> > # BB#0:
> >         ldi r24, #1
> >         mov r24, r24
>
> What's up with the redundant mov? Or will future optimization take care of
> removing this?
>
> >         ret
> >         .size   func, .-func
> >
> >
>
Good question, I haven't looked into (with any detail) how LLVM IR is
converted to native assembly.
I will probable spend some time later this weekend checking that out.

Re: [avr-llvm-devel] Windows build

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

 

> -----Original Message-----
> From: John Myers [mailto:ato...@gm...] 
> Sent: Friday, December 04, 2009 10:18 PM
> To: avr...@li...
> Subject: [avr-llvm-devel] Windows build
> 
>  
> I had a pain free build using Visual Studio C++ 2008 express 
> edition and CMake on Windows XP.

Congratulations!
  
> C:\_projects_\build_llvm\bin\Debug>llc.exe -O0 -filetype=asm 
> -mcpu=atmega128 reti8.ll -o -
>         .file   "reti8.ll"
> 
>         .text
>         .align  16
>         .globl  func

Can we change the directive to be the full spelling?: .global

>         .type   func,@function
> func:
> # BB#0:
>         ldi r24, #1
>         mov r24, r24

What's up with the redundant mov? Or will future optimization take care of removing this?

>         ret
>         .size   func, .-func
>  
> 

[avr-llvm-devel] Windows build

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

I had a pain free build using Visual Studio C++ 2008 express edition and
CMake on Windows XP.

C:\_projects_\build_llvm>cmake -G "Visual Studio 9 2008"
-DLLVM_TARGETS_TO_BUILD="AVR" -DCMAKE_BUILD_TYPE=Debug -DLLVM_BUILD_TOOLS=ON
-DLLVM_BUILD_EXAMPLES=OFF -DLLVM_ENABLE_THREADS=OFF ..\llvm

~~~~~

C:\_projects_\build_llvm\bin\Debug>llc.exe --version
Low Level Virtual Machine (http://llvm.org/):
  llvm version 2.7svn
  DEBUG build with assertions.
  Built Dec  4 2009 (20:35:54).
  Host: i686-pc-win32
  Host CPU: (unknown)
  Registered Targets:
    avr - AVR [experimental]
C:\_projects_\build_llvm\bin\Debug>llc.exe -O0 -filetype=asm -mcpu=atmega128
reti8.ll -o -
        .file   "reti8.ll"

        .text
        .align  16
        .globl  func
        .type   func,@function
func:
# BB#0:
        ldi r24, #1
        mov r24, r24
        ret
        .size   func, .-func

[avr-llvm-devel] [Fwd: [LLVMdev] DevMtg'09 slides]

[Josef E. <za...@za...>]

In case you missed it.

Some (maybe avr-llvm related) topics:

- Building backend in 24 hours
- Object Code Emission an llvm-mc

- Reimplementing llvm-gcc as a gcc plugin
- State of Clang


-------- Original Message --------
Subject: [LLVMdev] DevMtg'09 slides
Date: Mon, 30 Nov 2009 21:30:40 -0800
From: Chris Lattner <cla...@ap...>
To: LLVM Developers Mailing List <ll...@cs...>

Hi All,

The slides for all Developer Meeting talks are now online on the web page:
http://llvm.org/devmtg/2009-10/

The missing videos are still a work in progress,

-Chris
_______________________________________________
LLVM Developers mailing list
LL...@cs...         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Re: [avr-llvm-devel] new directory structure and documentation suggestion [RFC]

[Josef E. <za...@za...>]

FYI: directory structure changed according to variant 1 with one
exception: the docs folder is located in llvm/trunk/docs not
website/trunk/docs. website/trunk/docs is not used anymore in the llvm
repo and will be removed in the future.

Josef

Josef Eisl wrote:
> Hello,
> 
> I would like to suggest another change (hopefully the last one) to our
> svn structure.
> 
> Sooner or later we will need do customize either the llvm-gcc or the
> clang front-end (or both) and I think we should prepare the svn
> structure now. The new structure should be similar to the llvm svn
> repository to make things easier.
> 
> Variant 1: just move the current structure into a new llvm subfolder and
> create folders for the front-ends.
> 
> variant1
> |-- cfe
> |   |-- branches
> |   |-- tags
> |   `-- trunk
> |-- llvm
> |   |-- branches
> |   |-- tags
> |   `-- trunk
> |       |-- AVR
> |       |-- patches
> |       `-- testcases
> |-- llvm-gcc-4.2
> |   |-- branches
> |   |-- tags
> |   `-- trunk
> `-- website
>     |-- branches
>     |-- tags
>     `-- trunk
>         `-- docs
> 
> The second variant is very similar but the AVR folder is moved to
> trunk/lib/Target/AVR. The path is getting a little bit longer but it is
> more obvious where the AVR folder fits in into the llvm source tree.
> 
> variant2
> |-- cfe
> |   |-- branches
> |   |-- tags
> |   `-- trunk
> |-- llvm
> |   |-- branches
> |   |-- tags
> |   `-- trunk
> |       |-- lib
> |       |   `-- Target
> |       |       `-- AVR
> |       |-- patches
> |       `-- testcases
> |-- llvm-gcc-4.2
> |   |-- branches
> |   |-- tags
> |   `-- trunk
> `-- website
>     |-- branches
>     |-- tags
>     `-- trunk
>         `-- docs
> 
> 
> The other idea is about documentation. Like in LLVM we could create a
> website folder and use html files for documentation and maybe put them
> on http://avr-llvm.sourceforge.net.
> I am thinking of docs about:
> 
> - Getting Started: how to prepare the llvm source tree and compile llvm
> with avr support
> - Developer Guide: Commit rules, Coding Standards, etc
> - Testing: test cases, test framework, etc
> 
> And maybe a front page with links to the ML and the other documents.
> 
> I've some early drafts for these documents and will post the for
> discussion if we decide to go this way.
> 
> All comments are very welcome.
> 
> BR
> Josef
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> avr-llvm-devel mailing list
> avr...@li...
> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
> 

Re: [avr-llvm-devel] new directory structure and documentationsuggestion [RFC]

[Josef E. <za...@za...>]

Weddington, Eric wrote:
> Excellent!
> 
> I'm good with the Coding Standards.
> 
> I have two small suggestions for the Commit Guidelines:
> 
> - There is this line:
> $ patch -p0 < ../avr-llvm/trunk/patches/XXX.diff  # apply patches
> Can we explicitly list the patch files? Like what is done in the "Getting Started" section. I always worry when I see stuff like "XXX" and it is not explained anywhere what that means.
> 
> - Small nit on English. This sentence:
> "If the working copy does not compile the changes must be in repository for any reason whatsoever I suggest creating a branch, ..."
> Should be:
> "If the working copy does not compile and the changes must be in repository for any reason whatsoever, then we suggest creating a branch, ..."
> Note that the "I" is changed to "we" because we are speaking as a group of developers for any newcomers to development.
> 
> Other than those two small things, it all looks great!

Thanks for the input. I've committed the updated files to trunk/docs.
Lets try to keep these docs up-to-date (patches, etc.).

Josef

Re: [avr-llvm-devel] new directory structure and documentationsuggestion [RFC]

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

Excellent!

I'm good with the Coding Standards.

I have two small suggestions for the Commit Guidelines:

- There is this line:
$ patch -p0 < ../avr-llvm/trunk/patches/XXX.diff  # apply patches
Can we explicitly list the patch files? Like what is done in the "Getting Started" section. I always worry when I see stuff like "XXX" and it is not explained anywhere what that means.

- Small nit on English. This sentence:
"If the working copy does not compile the changes must be in repository for any reason whatsoever I suggest creating a branch, ..."
Should be:
"If the working copy does not compile and the changes must be in repository for any reason whatsoever, then we suggest creating a branch, ..."
Note that the "I" is changed to "we" because we are speaking as a group of developers for any newcomers to development.

Other than those two small things, it all looks great!

Now I need to go actually try and build the tools... ;-)

Eric Weddington

> -----Original Message-----
> From: Josef Eisl [mailto:za...@za...] 
> Sent: Tuesday, December 01, 2009 8:56 AM
> To: Weddington, Eric
> Cc: avr...@li...
> Subject: Re: [avr-llvm-devel] new directory structure and 
> documentationsuggestion [RFC]
> 
> Weddington, Eric wrote:
> > Regarding documentation: Again, I'm not attached to any 
> particular layout or method. I do think that you should post 
> your early drafts; they don't have to be perfect in order to 
> have something that we can all work with. My only 
> recommendation is to not spend a whole lot of time on the 
> formatting of the documentation. Most of our documentation 
> should be eventually migrated upstream to the LLVM project.
> 
> I've attached an archive with my drafts for a Getting Started and a
> Development Guidelines document.
> 
> The content is up for discussion.
> 
> Josef
> 

Re: [avr-llvm-devel] new directory structure and documentationsuggestion [RFC]

[Josef E. <za...@za...>]

Weddington, Eric wrote:
> Regarding documentation: Again, I'm not attached to any particular layout or method. I do think that you should post your early drafts; they don't have to be perfect in order to have something that we can all work with. My only recommendation is to not spend a whole lot of time on the formatting of the documentation. Most of our documentation should be eventually migrated upstream to the LLVM project.

I've attached an archive with my drafts for a Getting Started and a
Development Guidelines document.

The content is up for discussion.

Josef

Re: [avr-llvm-devel] new directory structure and documentation suggestion [RFC]

[Josef E. <za...@za...>]

John Myers wrote:
> I vote for using varient1.
> sourceforge has hosted apps like MediaWiki which could be used for
> documentation.
> I've never used any of them so I don't know if it would be any
> easier/better to use.

I also thought about a wiki software (actually about Trac..) but I
rejected that idea:

*) If we use a wiki the documentation is not distributed with the source
code. So we would need to write some basic instructions e.g. a README
and that would be redundant.
*) If the documentations uses a different system that the source it is
very likely to forget to edit the docs (e.g. if a new patch is added,
path were changed, etc.)
*) LLVM uses HTML so migration would be easier.
*) With HTML files we are independent from sourceforge.
*) I believe most of us know some basic HTML constructs. With a wiki we
would need to learn new formating syntax.

Although wikis are great software but as long as our user base is pretty
much the same as our developer base I think we are better off with html.

> 
> On Sun, Nov 29, 2009 at 6:59 AM, Josef Eisl <za...@za...> wrote:
> 
>     Hello,
> 
>     I would like to suggest another change (hopefully the last one) to our
>     svn structure.
> 
>     Sooner or later we will need do customize either the llvm-gcc or the
>     clang front-end (or both) and I think we should prepare the svn
>     structure now. The new structure should be similar to the llvm svn
>     repository to make things easier.
> 
>     Variant 1: just move the current structure into a new llvm subfolder and
>     create folders for the front-ends.
> 
>     variant1
>     |-- cfe
>     |   |-- branches
>     |   |-- tags
>     |   `-- trunk
>     |-- llvm
>     |   |-- branches
>     |   |-- tags
>     |   `-- trunk
>     |       |-- AVR
>     |       |-- patches
>     |       `-- testcases
>     |-- llvm-gcc-4.2
>     |   |-- branches
>     |   |-- tags
>     |   `-- trunk
>     `-- website
>        |-- branches
>        |-- tags
>        `-- trunk
>            `-- docs
> 
>     The second variant is very similar but the AVR folder is moved to
>     trunk/lib/Target/AVR. The path is getting a little bit longer but it is
>     more obvious where the AVR folder fits in into the llvm source tree.
> 
>     variant2
>     |-- cfe
>     |   |-- branches
>     |   |-- tags
>     |   `-- trunk
>     |-- llvm
>     |   |-- branches
>     |   |-- tags
>     |   `-- trunk
>     |       |-- lib
>     |       |   `-- Target
>     |       |       `-- AVR
>     |       |-- patches
>     |       `-- testcases
>     |-- llvm-gcc-4.2
>     |   |-- branches
>     |   |-- tags
>     |   `-- trunk
>     `-- website
>        |-- branches
>        |-- tags
>        `-- trunk
>            `-- docs
> 
> 
>     The other idea is about documentation. Like in LLVM we could create a
>     website folder and use html files for documentation and maybe put them
>     on http://avr-llvm.sourceforge.net.
>     I am thinking of docs about:
> 
>     - Getting Started: how to prepare the llvm source tree and compile llvm
>     with avr support
>     - Developer Guide: Commit rules, Coding Standards, etc
>     - Testing: test cases, test framework, etc
> 
>     And maybe a front page with links to the ML and the other documents.
> 
>     I've some early drafts for these documents and will post the for
>     discussion if we decide to go this way.
> 
>     All comments are very welcome.
> 
>     BR
>     Josef
> 
>     ------------------------------------------------------------------------------
>     Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>     30-Day
>     trial. Simplify your report design, integration and deployment - and
>     focus on
>     what you do best, core application coding. Discover what's new with
>     Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>     _______________________________________________
>     avr-llvm-devel mailing list
>     avr...@li...
>     <mailto:avr...@li...>
>     https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
> 
>