Thread: [avr-llvm-devel] current status and future direction of the avr-llvm project

This is the AVR port of LLVM.

Status: Pre-Alpha

Brought to you by: arcanum, atomicdog407, joeezapster

avr-llvm-devel

[avr-llvm-devel] current status and future direction of the avr-llvm project

From: Josef E. <za...@za...> - 2009-11-24 22:26:46

Hello!

I want to summarize the current status of the avr-llvm project and the
next steps from my point of view.

The current version of llvm is 2.6 and was release on 23.10.09 [1].
The 2.6 branch of avr-llvm can be built (successfully on linux)
following the procedure described below:

- Get the LLVM 2.6 release (e.g. via svn)
- Get the avr-llvm 2.6 branch
- setup the build environment
- configure and build

On Linux:

$ svn co http://llvm.org/svn/llvm-project/llvm/tags/RELEASE_26 llvm
$ svn co
https://avr-llvm.svn.sourceforge.net/svnroot/avr-llvm/branches/release_26
avr-llvm
$ cp -rf avr-llvm/AVR llvm/lib/Target/
$ cd llvm
$ patch -p0 < ../avr-llvm/patches/configure.ac.diff
$ patch -p0 < ../avr-llvm/patches/configure.diff
$ patch -p0 < ../avr-llvm/patches/triple.diff
$ cd ..
$ mkdir build
$ cd build
$ ../llvm/configure --prefix=$HOME/usr/avr-llvm/ --disable-optimized
--enable-targets=avr
$ make

Compiling against llvm trunk is currently broken but since the 2.6
release is not that old this should be easy to fix.

The question is if we should work on trunk or on the latest release? I
would prefer working on trunk.

Anyway, the avr-llvm tools like llc don't produce avr assembly code yet.

In my opinion we should start with simple llvm IR test cases like

define i8 @main() {
  ret i8 1
}

and add at least one test case for every feature added.

As soon as the back-end produces correct code we should consider setting
up a testing framework.

Another topic for discussion is documentation. In my opinion a good
project documentation is essential in order to get more people into
development.
We should also talk about coding standards, commit guidelines, etc.

It is easier to do this at the 'beginning' than later.

Any Suggestions? Thoughts?

BR
Josef

[1] http://llvm.org/releases/2.6/docs/ReleaseNotes.html

Re: [avr-llvm-devel] current status and future direction of theavr-llvm project

From: Weddington, E. <Eri...@at...> - 2009-11-24 23:05:57

Hi Josef,

Thanks for the summary, and the build description, both are very helpful.

I understand the desire for working against the trunk, especially if avr-llvm currently doesn't build against the trunk then we should definitely get that fixed. Working against the trunk would allow us to more easily merge upstream when the time comes. Can you describe in a bit more detail how this would work? How do we keep keep synchronized?

I like your idea about setting up test cases as we get features working. Do you have some thoughts on how we do this, or rather where do these test cases fit within the tree? How does this work when we commit upstream? On a similar note, I was looking at the proceedings of the 2009 LLVM Developers Meeting, here <http://llvm.org/devmtg/2009-10/>, and at the presentation "Tutorial: Building backend in 24 hours - A step by step tutorial to build a backend.". Here's a link to the slides: <http://llvm.org/devmtg/2009-10/Korobeynikov_BackendTutorial.pdf>. The author recommends the same step-by-step process with test cases.

I don't have any recommendations on commit guidelines, though I am open to suggestions if anyone has any.

Concerning coding standards, I have two recommendations:
1. Bracket, brace placement. I generally prefer when they are in the same column. For example, change from this:

def MEMri : Operand<i8> {
  let PrintMethod = "printMemOperand";
  let MIOperandInfo = (ops GPRegs, i16imm);
}

To this:

def MEMri : Operand<i8>
{
  let PrintMethod = "printMemOperand";
  let MIOperandInfo = (ops GPRegs, i16imm);
}

For my eyes it just makes it easier to keep track of nesting levels, and to make sure that the blocks are closed properly.

2. Explicit brackets, braces. I know that one can have a single line from an 'if' statement withouts brackets/braces, but I prefer to make them explicit. It may be the case that we have to add or remove lines within the block later and it's easier to already have the brackets/braces in place. I learned this practice years ago when I was writing code for a medical device which required a lot of code review as well as standards approval. For example change from this:

let neverHasSideEffects = 1 in
  def NOP : Pseudo<0x00, (outs), (ins), "nop", []>;

To this:

let neverHasSideEffects = 1 in
{
  def NOP : Pseudo<0x00, (outs), (ins), "nop", []>;
}

Granted, I understand that these formatting suggestions would be for the AVR-specific files only. Anything that touches the generic portions of LLVM should follow the general format of the file that is being modified.

IMHO, I generally prefer to have indentation of 4 spaces rather than 2, but I can be flexible on that point.

I am willing to do the reformatting of the code to conform to the suggestions above.

Other than that I think that the LLVM project has some coding standard guidelines that we should follow.

Lastly, on documentation, I agree with you that we should have good documentation. Though I would like to have some specific suggestions on what needs to be done in this area. I haven't had a chance to look at what exists yet.

Eric Weddington


> -----Original Message-----
> From: Josef Eisl [mailto:za...@za...] 
> Sent: Tuesday, November 24, 2009 3:27 PM
> To: avr...@li...
> Subject: [avr-llvm-devel] current status and future direction 
> of theavr-llvm project
> 
> Hello!
> 
> I want to summarize the current status of the avr-llvm project and the
> next steps from my point of view.
> 
> The current version of llvm is 2.6 and was release on 23.10.09 [1].
> The 2.6 branch of avr-llvm can be built (successfully on linux)
> following the procedure described below:
> 
> - Get the LLVM 2.6 release (e.g. via svn)
> - Get the avr-llvm 2.6 branch
> - setup the build environment
> - configure and build
> 
> On Linux:
> 
> $ svn co http://llvm.org/svn/llvm-project/llvm/tags/RELEASE_26 llvm
> $ svn co
> https://avr-llvm.svn.sourceforge.net/svnroot/avr-llvm/branches
> /release_26
> avr-llvm
> $ cp -rf avr-llvm/AVR llvm/lib/Target/
> $ cd llvm
> $ patch -p0 < ../avr-llvm/patches/configure.ac.diff
> $ patch -p0 < ../avr-llvm/patches/configure.diff
> $ patch -p0 < ../avr-llvm/patches/triple.diff
> $ cd ..
> $ mkdir build
> $ cd build
> $ ../llvm/configure --prefix=$HOME/usr/avr-llvm/ --disable-optimized
> --enable-targets=avr
> $ make
> 
> Compiling against llvm trunk is currently broken but since the 2.6
> release is not that old this should be easy to fix.
> 
> The question is if we should work on trunk or on the latest release? I
> would prefer working on trunk.
> 
> Anyway, the avr-llvm tools like llc don't produce avr 
> assembly code yet.
> 
> In my opinion we should start with simple llvm IR test cases like
> 
> define i8 @main() {
>   ret i8 1
> }
> 
> and add at least one test case for every feature added.
> 
> As soon as the back-end produces correct code we should 
> consider setting
> up a testing framework.
> 
> Another topic for discussion is documentation. In my opinion a good
> project documentation is essential in order to get more people into
> development.
> We should also talk about coding standards, commit guidelines, etc.
> 
> It is easier to do this at the 'beginning' than later.
> 
> Any Suggestions? Thoughts?
> 
> BR
> Josef
> 
> [1] http://llvm.org/releases/2.6/docs/ReleaseNotes.html
> 
> --------------------------------------------------------------
> ----------------
> 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] current status and future direction of the avr-llvm project

From: John M. <ato...@gm...> - 2009-11-25 04:23:09

On Tue, Nov 24, 2009 at 2:26 PM, Josef Eisl <za...@za...> wrote:

>
>
> Compiling against llvm trunk is currently broken but since the 2.6
> release is not that old this should be easy to fix.
>
> The question is if we should work on trunk or on the latest release? I
> would prefer working on trunk.
>
>
I believe working on the trunk is important otherwise we could fall too far
behind the current state of the LLVM src. I think the major issue with
working on the trunk is the LLVM developers seem very active making it
harder to put time into making the AVR port work rather then keeping up with
new features and re-factoring of the src code. I started working on the 2.6
branch since I'm still trying to learn the structure of LLVM but they keep
on changing/improving it in the trunk.

Re: [avr-llvm-devel] current status and future direction of theavr-llvm project

From: Weddington, E. <Eri...@at...> - 2009-11-25 06:50:14

 

> -----Original Message-----
> From: John Myers [mailto:ato...@gm...] 
> Sent: Tuesday, November 24, 2009 9:23 PM
> To: avr...@li...
> Subject: Re: [avr-llvm-devel] current status and future 
> direction of theavr-llvm project
> 
> 
> 
> On Tue, Nov 24, 2009 at 2:26 PM, Josef Eisl 
> <za...@za...> wrote:
> 
> 
> 
> 
> 	Compiling against llvm trunk is currently broken but 
> since the 2.6
> 	release is not that old this should be easy to fix.
> 	
> 	The question is if we should work on trunk or on the 
> latest release? I
> 	would prefer working on trunk.
> 	
> 	
> 
> 
> I believe working on the trunk is important otherwise we 
> could fall too far behind the current state of the LLVM src. 
> I think the major issue with working on the trunk is the LLVM 
> developers seem very active making it harder to put time into 
> making the AVR port work rather then keeping up with new 
> features and re-factoring of the src code. I started working 
> on the 2.6 branch since I'm still trying to learn the 
> structure of LLVM but they keep on changing/improving it in the trunk.

That's why I'm hoping that combining our resources and work can help to move this project forward.

So at least we all agree that we should work on the trunk. It does make the most sense.

Re: [avr-llvm-devel] current status and future direction of theavr-llvm project

From: John M. <ato...@gm...> - 2009-11-28 02:07:06

RE: patch creation guidelines / standards

Hello,

Do you guys prefer making separate patch files for each source file or
making one patch file based on the type of 'fix' it was for.
For example we have a Triple.h.diff and Triple.cpp.diff but we could make
just one instead like...

$    svn diff lib/Support/Triple.cpp include/llvm/ADT/Triple.h > Triple.dif