Menu
▾
▴
avr-llvm-devel — Developers mailing list.
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(26) |
Dec
(15) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(14) |
Oct
(16) |
Nov
(36) |
Dec
(3) |
| 2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
(17) |
May
(9) |
Jun
(6) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(4) |
| 2012 |
Jan
(22) |
Feb
(12) |
Mar
(39) |
Apr
(31) |
May
(42) |
Jun
(35) |
Jul
(32) |
Aug
(2) |
Sep
(5) |
Oct
|
Nov
|
Dec
(9) |
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(121) |
Jul
(61) |
Aug
(7) |
Sep
(8) |
Oct
(6) |
Nov
|
Dec
(1) |
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Borja F. <bor...@gm...> - 2012-02-03 16:09:43
|
Ahh ok, I will take a look then. Update: I've already implemented conditional branches for if() conditions (BR_CC node). I still need to work on overriding some virtual functions in some interfaces to improve the generated code. Then I will move to SETCC and SELECT nodes which are used in things like: a = (b > c) and a = (b > c) ? 1 : 2 respectively. I'm happy because we can now compile loops :) 2012/1/31 Weddington, Eric <Eri...@at...> > Hi Borja, > > Thanks for the ping. > > Unfortunately the best place to see how address spaces work is still the > GCC source code, and documentation :-( > > Eric > > > -----Original Message----- > > From: Borja Ferrer [mailto:bor...@gm...] > > Sent: Tuesday, January 31, 2012 7:08 AM > > To: Weddington, Eric > > Cc: Sherard Dames; avr...@li... > > Subject: Re: [avr-llvm-devel] Current Status? > > > > Update: I've already started working on conditional branches and > compares. > > Eric ping? > > > > > > 2012/1/20 Borja Ferrer <bor...@gm...> > > > > > > Ahh ok thanks for the info Eric, about the work on doubles, what > sort of > > support is it? shouldn't that go into write the math functions in the > C > > library? or do you mean removing the constraint of making double a > float? > > Is there a place on how the multiple address space feature will > work, we > > should implement this aswell in an early stage so it's important that > we see > > how it works to be compatible with what gcc does. > > > > > > 2012/1/16 Weddington, Eric <Eri...@at...> > > > > > > > > > > > > > -----Original Message----- > > > From: Borja Ferrer [mailto:bor...@gm...] > > > > > Sent: Friday, January 13, 2012 9:19 AM > > > To: Weddington, Eric > > > Cc: Sherard Dames; > avr...@li... > > > Subject: Re: [avr-llvm-devel] Current Status? > > > > > > > > Eric one more thing, you mentioned that some work has > been done > > lately > > in > > > gcc's backend, can you tell me what are the main > features added > > and if > > > there are any code quality improvements. > > > > > > Umpf. There's been so much happening, I'm not sure if I > can > > remember it > > all > > > > - Improvements in the AVR backend, especially a number > of missed > > optimization bugs fixed > > > > - The beginning of a Multiple Address Spaces feature > > > > - The beginning of 24-bit types, mainly used for > Multiple Address > > Spaces > > (i.e. large code space, or large data space) > > > > - Some work done on 64-bit double types > > > > And other fixed bugs. > > > > Eric > > > > > > > > |
|
From: Weddington, E. <Eri...@at...> - 2012-01-31 14:43:46
|
Hi Borja, Thanks for the ping. Unfortunately the best place to see how address spaces work is still the GCC source code, and documentation :-( Eric > -----Original Message----- > From: Borja Ferrer [mailto:bor...@gm...] > Sent: Tuesday, January 31, 2012 7:08 AM > To: Weddington, Eric > Cc: Sherard Dames; avr...@li... > Subject: Re: [avr-llvm-devel] Current Status? > > Update: I've already started working on conditional branches and compares. > Eric ping? > > > 2012/1/20 Borja Ferrer <bor...@gm...> > > > Ahh ok thanks for the info Eric, about the work on doubles, what sort of > support is it? shouldn't that go into write the math functions in the C > library? or do you mean removing the constraint of making double a float? > Is there a place on how the multiple address space feature will work, we > should implement this aswell in an early stage so it's important that we see > how it works to be compatible with what gcc does. > > > 2012/1/16 Weddington, Eric <Eri...@at...> > > > > > > > -----Original Message----- > > From: Borja Ferrer [mailto:bor...@gm...] > > > Sent: Friday, January 13, 2012 9:19 AM > > To: Weddington, Eric > > Cc: Sherard Dames; avr...@li... > > Subject: Re: [avr-llvm-devel] Current Status? > > > > > Eric one more thing, you mentioned that some work has been done > lately > in > > gcc's backend, can you tell me what are the main features added > and if > > there are any code quality improvements. > > > Umpf. There's been so much happening, I'm not sure if I can > remember it > all > > - Improvements in the AVR backend, especially a number of missed > optimization bugs fixed > > - The beginning of a Multiple Address Spaces feature > > - The beginning of 24-bit types, mainly used for Multiple Address > Spaces > (i.e. large code space, or large data space) > > - Some work done on 64-bit double types > > And other fixed bugs. > > Eric > > > |
|
From: Borja F. <bor...@gm...> - 2012-01-31 14:07:54
|
Update: I've already started working on conditional branches and compares. Eric ping? 2012/1/20 Borja Ferrer <bor...@gm...> > Ahh ok thanks for the info Eric, about the work on doubles, what sort of > support is it? shouldn't that go into write the math functions in the C > library? or do you mean removing the constraint of making double a float? > Is there a place on how the multiple address space feature will work, we > should implement this aswell in an early stage so it's important that we > see how it works to be compatible with what gcc does. > > 2012/1/16 Weddington, Eric <Eri...@at...> > > >> >> >> > -----Original Message----- >> > From: Borja Ferrer [mailto:bor...@gm...] >> > Sent: Friday, January 13, 2012 9:19 AM >> > To: Weddington, Eric >> > Cc: Sherard Dames; avr...@li... >> > Subject: Re: [avr-llvm-devel] Current Status? >> > >> > Eric one more thing, you mentioned that some work has been done lately >> in >> > gcc's backend, can you tell me what are the main features added and if >> > there are any code quality improvements. >> >> Umpf. There's been so much happening, I'm not sure if I can remember it >> all >> >> - Improvements in the AVR backend, especially a number of missed >> optimization bugs fixed >> >> - The beginning of a Multiple Address Spaces feature >> >> - The beginning of 24-bit types, mainly used for Multiple Address Spaces >> (i.e. large code space, or large data space) >> >> - Some work done on 64-bit double types >> >> And other fixed bugs. >> >> Eric >> > > |
|
From: Borja F. <bor...@gm...> - 2012-01-20 19:02:46
|
Ahh ok thanks for the info Eric, about the work on doubles, what sort of support is it? shouldn't that go into write the math functions in the C library? or do you mean removing the constraint of making double a float? Is there a place on how the multiple address space feature will work, we should implement this aswell in an early stage so it's important that we see how it works to be compatible with what gcc does. 2012/1/16 Weddington, Eric <Eri...@at...> > > > > > -----Original Message----- > > From: Borja Ferrer [mailto:bor...@gm...] > > Sent: Friday, January 13, 2012 9:19 AM > > To: Weddington, Eric > > Cc: Sherard Dames; avr...@li... > > Subject: Re: [avr-llvm-devel] Current Status? > > > > Eric one more thing, you mentioned that some work has been done lately > in > > gcc's backend, can you tell me what are the main features added and if > > there are any code quality improvements. > > Umpf. There's been so much happening, I'm not sure if I can remember it > all > > - Improvements in the AVR backend, especially a number of missed > optimization bugs fixed > > - The beginning of a Multiple Address Spaces feature > > - The beginning of 24-bit types, mainly used for Multiple Address Spaces > (i.e. large code space, or large data space) > > - Some work done on 64-bit double types > > And other fixed bugs. > > Eric > |
|
From: Borja F. <bor...@gm...> - 2012-01-20 18:58:32
|
Hello, first thank both of you for working into this. As Joshua suggested I would start by working with simple very tests, I haven't checked other backends but I'm sure they have to check simple things like arith instructions and calling conventions as Sherard did. However I would start with arith instructions because they are easier and shorter to write, and very important, testing all datatypes (from i8 to i64). Also testing both regs, and imm instruction operands. Ideally we should test that each instruction for every datatype produces the correct asm output. Note on this, for now don't write tests on multiplications and shifts, the first is not implemented yet, and for the second they require special treatment that we will discuss later. Then, move on to testing calling conventions, so check if the right registers are being read as input arguments of a function, check if the right registers are being passed in function calls etc. Some info about calling conventions, I haven't tested passing big structs byval or returning them so I wouldn't add tests for this for now, maybe make a note on this to check in it the future when it's done. Ah, and don't test varargs, they are a bit tricky to implement, and they arent high priority for now. One note about Joshua's test, i dont know if CHECK is case sensitive, but all instructions are lowercase in our backend, so please careful with this. Another thing, i have a patched version of clang that doesn't emit the "signext" argument attribute in functions, we dont want to signext an i8 to i16 beause the upper reg is not used, so we may be able to use it for other purposes. I can't remember now if the patch in svn addresses this or not, but it was something easy to do in clang, so you may want to add it to your code. For these simple tests you can use GCC to check the produced asm because we should produce exactly the same code, and check the generated IR that LLVM produces like Joshua showed, that way you can write directly tests in C instead of IR. |
|
From: Joshua N. <ne...@em...> - 2012-01-19 05:27:39
|
Hey Sherard,
I don't know if that is the first test you have written, but I would start with the easy tests first. (see attached, if that works on this list serve) But as far as the test you would like to write based on calling conditions, you are right, the tests written are quite strict, specific, or simply there just to check compilation, and in order to write a test for something like a call, that you would need to know the underlying code, so until Borja commits his code so far you will not be able to write code for this part.
For a digression, as far as the philosophy behind having very strict tests, from what I can tell is that once we have decided on a way to compile a piece of LLVM IR it should compile the same way ever time until we change code that affects it. This is a great way to catch code that directly or indirectly affects the testing IR compilation, if we somehow tweak the compilation to work better, it is ok that we fail, for at that time we check the failed code, see that it works correctly (hopefully even better) and tweak the test. Knowing this the smaller and more specific the test is, the better, for instance, write a couple test for a calling convention, each one testing a specific part of the call. I am sorry if I have written too much here, my formal training is in Biology, so I do not expect much prior knowledge from people, as I am often left out in the dark when people do not explain lots of things to the T.
Anyways, about how to go about writing the tests, I would first patch clang (I don't know if patch in the repository is up to date, so I attached mine) and execute the following `clang -emit-llvm -ccc-host-triple avr -Os -S -o - scratch.c`, this will emit LLVM IR based on scratch.c so you know what valid IR to use, then use llc to compile this IR into assembly `llc -march=avr arithmetic_instruction_selection.ll -o -` (this you will need the actual backend code, I am currently using my own avr backend code) If it outputs correct assembly, write the test to conform to this output, if not. figure out why it does not and let us know or help fix it. Anyways, I hope this helps, that you get my attached files and do not take offense.
Joshua
Joshua Nedrud
Master of Science, Biomedical Engineering
Example, if the attached files do not send:
; RUN: llc < %s -march=avr | FileCheck %s
define signext i8 @add8rr(i8 signext %a, i8 signext %b) nounwind readnone optsize {
%1 = add i8 %a, %b
ret i8 %1
}
; CHECK: add8rr:
; CHECK: ADD
This test checks for the function definition add8rr, and then checks if the assembly instruction ADD follows this, which it should for this is about the simplest LLVM IR function you can get when run with -Os optimizations.
|
|
From: Sherard D. <sc...@gm...> - 2012-01-19 01:12:56
|
Hey everyone,
So I started to work on writing some tests, and... not as easy as I
thought it would be. Writing the tests are easy, the hard part is
*defining* what is correct. I've mostly been studying the code GCC
produces, however I don't want to end up writing tests that verify that
the output is just like what GCC would produce, or otherwise limit the
possible output.
I have looked at the tests written for most of the other backends, and
what I see usually seems either really strict (restricting possible code
generation), really specific (targeted at a specific bug report), or
simply tests that don't check their output.
Pasted below is one of the test files I've written. Any comments would
be greatly appreciated, as I seem to be having a rather difficult time
grasping the idea of verifying correct code, for which multiple pieces
of code can all be considered correct.
%struct.Large = type { i32, i32, i32, i32 }
declare i8 @targetCallRegisters8(i8, i8, i8, i8)
declare i32 @targetCallRegisters32(i32, i32, i32, i32)
declare i32 @targetCallStack(i32, %struct.Large)
define i8 @callerStack(i32 %a, %struct.Large %b) {
; CHECK: callerStack
; CHECK: in [[SSUBRL:r[0-9]+]], 0x3D
; CHECK: in [[SSUBRH:r[0-9]+]], 0x3E
; CHECK: sbiw [[STACKRL]], 0x10
; CHECK: out 0x3E, [[SSUBRH]]
; CHECK: out 0x3D, [[SSUBRL]]
; CHECK: ldi r22, 0xE0
; CHECK: ldi r23, 0x00
; CHECK: ldi r24, 0x00
; CHECK: ldi r25, 0x00
; CHECK: {{[eir]*call}}
; CHECK: in [[SADDRL:r[0-9]+]], 0x3D
; CHECK: in [[SADDRH:r[0-9]+]], 0x3E
; CHECK: adiw [[STACKRL]], 0x10
; CHECK: out 0x3E, [[SADDRH]]
; CHECK: out 0x3D, [[SADDRL]]
%1 = call i32 @targetCallStack(i32 224, %struct.Large %b)
ret i8 0
}
define i8 @callerRegisters8() {
; CHECK: callerRegisters8
; CHECK: ldi r24, 0xA0
; CHECK: ldi r22, 0xB0
; CHECK: ldi r20, 0xC0
; CHECK: ldi r18, 0xD0
; CHECK: {{[eir]*call}}
%1 = call i8 @targetCallRegisters8(i8 160, i8 176, i8 192, i8 208)
ret i8 %1
}
define i8 @callerRegisters32() {
; CHECK: callerRegisters32
; CHECK: ldi r22, 0xA0
; CHECK: ldi r18, 0xB0
; CHECK: ldi [[TMPREG1:r[0-9]+]], 0xC0
; CHECK: mov r14, [[TMPREG1]]
; CHECK: ldi [[TMPREG2:r[0-9]+]], 0xD0
; CHECK: mov r10, [[TMPREG2]]
; CHECK: {{[eir]*call}}
%1 = call i32 @targetCallRegisters32(i32 160, i32 176, i32 192, i32
208)
ret i8 0
}
|
|
From: Weddington, E. <Eri...@at...> - 2012-01-16 17:49:20
|
> -----Original Message----- > From: Borja Ferrer [mailto:bor...@gm...] > Sent: Friday, January 13, 2012 9:19 AM > To: Weddington, Eric > Cc: Sherard Dames; avr...@li... > Subject: Re: [avr-llvm-devel] Current Status? > > Eric one more thing, you mentioned that some work has been done lately in > gcc's backend, can you tell me what are the main features added and if > there are any code quality improvements. Umpf. There's been so much happening, I'm not sure if I can remember it all - Improvements in the AVR backend, especially a number of missed optimization bugs fixed - The beginning of a Multiple Address Spaces feature - The beginning of 24-bit types, mainly used for Multiple Address Spaces (i.e. large code space, or large data space) - Some work done on 64-bit double types And other fixed bugs. Eric |
|
From: Borja F. <bor...@gm...> - 2012-01-13 16:19:37
|
Eric one more thing, you mentioned that some work has been done lately in gcc's backend, can you tell me what are the main features added and if there are any code quality improvements. 2012/1/13 Borja Ferrer <bor...@gm...> > Ahh I see, well any function call that needs 8 bytes passed through the > stack will do. > > 2012/1/12 Weddington, Eric <Eri...@at...> > > >> Well, then, I'm not sure what to tell you. I agree it seems stupid, if >> the compiler generates it that way. >> >> Another reason why I suggested a real test case is that way I can check >> what different gcc versions are doing, and specifically what gcc trunk >> is doing now. There's been a lot of new work going on with the avr port >> in gcc. I'd like to be able to do some comparisons. >> >> Eric >> >> > -----Original Message----- >> > From: Borja Ferrer [mailto:bor...@gm...] >> > Sent: Thursday, January 12, 2012 2:16 PM >> > To: Weddington, Eric >> > Cc: Sherard Dames; avr...@li... >> > Subject: Re: [avr-llvm-devel] Current Status? >> > >> > Haha, well in avr asm it would be something like: >> > >> > in r30, 0x3d >> > in r31, 0x3e >> > sbiw r30, 0x08 >> > in r0, 0x3f >> > cli >> > out 0x3e, r30 >> > out 0x3f, r0 >> > out 0x3d, r31 <--- 8 instructions to allocate 8 bytes of stack >> space! >> > std Z+1, reg1 <-- move 8 regs into the stack >> > std Z+2, reg2 >> > .... >> > std Z+8, reg8 >> > call foo >> > >> > instead of: >> > >> > push reg1 >> > push reg2 >> > ... >> > push reg8 >> > call foo >> > >> > You still have 8 instructions to copy the data into the stack for both >> > cases, but in the 2nd you've saved 8 instructions that manipulate SP. >> > Does it make more sense now? >> > >> > >> > 2012/1/12 Weddington, Eric <Eri...@at...> >> > >> > >> > >> > >> > > -----Original Message----- >> > > From: Borja Ferrer [mailto:bor...@gm...] >> > >> > > Sent: Thursday, January 12, 2012 1:25 PM >> > > To: Weddington, Eric >> > > Cc: Sherard Dames; avr...@li... >> > > Subject: Re: [avr-llvm-devel] Current Status? >> > > >> > >> > > For now I've implemented it the same way as gcc, but it's >> > something >> > that >> > > popped to me when i was coding it. >> > > I don't see how it saves space :) what I think is that you get >> the >> > same >> > > amount of pushes and std's when moving data into the stack no >> > matter >> > what >> > > method is used. The difference I see is that when using std, >> you >> > have >> > to >> > > adjust the SP pointer which creates an additional overhead. >> Just >> > to >> > > clarify I'm talking about the case when you want to pass >> function >> > > arguments before a function call, not in a function prologue >> which >> > is >> > a >> > > different story. >> > > >> > > In x86 it would be something like: >> > > >> > > sub esp, 8 >> > > mov DWORD PTR [esp], reg1 >> > > mov DWORD PTR [esp+4], reg 2 >> > > call foo >> > > ... >> > > >> > > instead of >> > > >> > > push reg1 >> > > push reg2 >> > > call foo >> > > ... >> > > >> > > which saves 1 instruction, but in our case doing "sub esp, 8" >> > means >> > adding >> > > 5 or 6 more instructions. >> > > >> > >> > >> > My x86 assembly is extremely rusty. ;-) >> > >> > Maybe we should work with a real test case... Do you have >> something >> > that >> > shows the issue? >> > >> > Eric >> > >> > >> > >> > >> >> > |
|
From: Borja F. <bor...@gm...> - 2012-01-12 23:01:38
|
Ahh I see, well any function call that needs 8 bytes passed through the stack will do. 2012/1/12 Weddington, Eric <Eri...@at...> > > Well, then, I'm not sure what to tell you. I agree it seems stupid, if > the compiler generates it that way. > > Another reason why I suggested a real test case is that way I can check > what different gcc versions are doing, and specifically what gcc trunk > is doing now. There's been a lot of new work going on with the avr port > in gcc. I'd like to be able to do some comparisons. > > Eric > > > -----Original Message----- > > From: Borja Ferrer [mailto:bor...@gm...] > > Sent: Thursday, January 12, 2012 2:16 PM > > To: Weddington, Eric > > Cc: Sherard Dames; avr...@li... > > Subject: Re: [avr-llvm-devel] Current Status? > > > > Haha, well in avr asm it would be something like: > > > > in r30, 0x3d > > in r31, 0x3e > > sbiw r30, 0x08 > > in r0, 0x3f > > cli > > out 0x3e, r30 > > out 0x3f, r0 > > out 0x3d, r31 <--- 8 instructions to allocate 8 bytes of stack > space! > > std Z+1, reg1 <-- move 8 regs into the stack > > std Z+2, reg2 > > .... > > std Z+8, reg8 > > call foo > > > > instead of: > > > > push reg1 > > push reg2 > > ... > > push reg8 > > call foo > > > > You still have 8 instructions to copy the data into the stack for both > > cases, but in the 2nd you've saved 8 instructions that manipulate SP. > > Does it make more sense now? > > > > > > 2012/1/12 Weddington, Eric <Eri...@at...> > > > > > > > > > > > -----Original Message----- > > > From: Borja Ferrer [mailto:bor...@gm...] > > > > > Sent: Thursday, January 12, 2012 1:25 PM > > > To: Weddington, Eric > > > Cc: Sherard Dames; avr...@li... > > > Subject: Re: [avr-llvm-devel] Current Status? > > > > > > > > For now I've implemented it the same way as gcc, but it's > > something > > that > > > popped to me when i was coding it. > > > I don't see how it saves space :) what I think is that you get > the > > same > > > amount of pushes and std's when moving data into the stack no > > matter > > what > > > method is used. The difference I see is that when using std, > you > > have > > to > > > adjust the SP pointer which creates an additional overhead. > Just > > to > > > clarify I'm talking about the case when you want to pass > function > > > arguments before a function call, not in a function prologue > which > > is > > a > > > different story. > > > > > > In x86 it would be something like: > > > > > > sub esp, 8 > > > mov DWORD PTR [esp], reg1 > > > mov DWORD PTR [esp+4], reg 2 > > > call foo > > > ... > > > > > > instead of > > > > > > push reg1 > > > push reg2 > > > call foo > > > ... > > > > > > which saves 1 instruction, but in our case doing "sub esp, 8" > > means > > adding > > > 5 or 6 more instructions. > > > > > > > > > My x86 assembly is extremely rusty. ;-) > > > > Maybe we should work with a real test case... Do you have > something > > that > > shows the issue? > > > > Eric > > > > > > > > > > |
|
From: Weddington, E. <Eri...@at...> - 2012-01-12 21:42:30
|
Well, then, I'm not sure what to tell you. I agree it seems stupid, if the compiler generates it that way. Another reason why I suggested a real test case is that way I can check what different gcc versions are doing, and specifically what gcc trunk is doing now. There's been a lot of new work going on with the avr port in gcc. I'd like to be able to do some comparisons. Eric > -----Original Message----- > From: Borja Ferrer [mailto:bor...@gm...] > Sent: Thursday, January 12, 2012 2:16 PM > To: Weddington, Eric > Cc: Sherard Dames; avr...@li... > Subject: Re: [avr-llvm-devel] Current Status? > > Haha, well in avr asm it would be something like: > > in r30, 0x3d > in r31, 0x3e > sbiw r30, 0x08 > in r0, 0x3f > cli > out 0x3e, r30 > out 0x3f, r0 > out 0x3d, r31 <--- 8 instructions to allocate 8 bytes of stack space! > std Z+1, reg1 <-- move 8 regs into the stack > std Z+2, reg2 > .... > std Z+8, reg8 > call foo > > instead of: > > push reg1 > push reg2 > ... > push reg8 > call foo > > You still have 8 instructions to copy the data into the stack for both > cases, but in the 2nd you've saved 8 instructions that manipulate SP. > Does it make more sense now? > > > 2012/1/12 Weddington, Eric <Eri...@at...> > > > > > > -----Original Message----- > > From: Borja Ferrer [mailto:bor...@gm...] > > > Sent: Thursday, January 12, 2012 1:25 PM > > To: Weddington, Eric > > Cc: Sherard Dames; avr...@li... > > Subject: Re: [avr-llvm-devel] Current Status? > > > > > For now I've implemented it the same way as gcc, but it's > something > that > > popped to me when i was coding it. > > I don't see how it saves space :) what I think is that you get the > same > > amount of pushes and std's when moving data into the stack no > matter > what > > method is used. The difference I see is that when using std, you > have > to > > adjust the SP pointer which creates an additional overhead. Just > to > > clarify I'm talking about the case when you want to pass function > > arguments before a function call, not in a function prologue which > is > a > > different story. > > > > In x86 it would be something like: > > > > sub esp, 8 > > mov DWORD PTR [esp], reg1 > > mov DWORD PTR [esp+4], reg 2 > > call foo > > ... > > > > instead of > > > > push reg1 > > push reg2 > > call foo > > ... > > > > which saves 1 instruction, but in our case doing "sub esp, 8" > means > adding > > 5 or 6 more instructions. > > > > > My x86 assembly is extremely rusty. ;-) > > Maybe we should work with a real test case... Do you have something > that > shows the issue? > > Eric > > > > |
|
From: Borja F. <bor...@gm...> - 2012-01-12 21:16:25
|
Haha, well in avr asm it would be something like: in r30, 0x3d in r31, 0x3e sbiw r30, 0x08 in r0, 0x3f cli out 0x3e, r30 out 0x3f, r0 out 0x3d, r31 <--- 8 instructions to allocate 8 bytes of stack space! std Z+1, reg1 <-- move 8 regs into the stack std Z+2, reg2 .... std Z+8, reg8 call foo instead of: push reg1 push reg2 ... push reg8 call foo You still have 8 instructions to copy the data into the stack for both cases, but in the 2nd you've saved 8 instructions that manipulate SP. Does it make more sense now? 2012/1/12 Weddington, Eric <Eri...@at...> > > > > -----Original Message----- > > From: Borja Ferrer [mailto:bor...@gm...] > > Sent: Thursday, January 12, 2012 1:25 PM > > To: Weddington, Eric > > Cc: Sherard Dames; avr...@li... > > Subject: Re: [avr-llvm-devel] Current Status? > > > > For now I've implemented it the same way as gcc, but it's something > that > > popped to me when i was coding it. > > I don't see how it saves space :) what I think is that you get the > same > > amount of pushes and std's when moving data into the stack no matter > what > > method is used. The difference I see is that when using std, you have > to > > adjust the SP pointer which creates an additional overhead. Just to > > clarify I'm talking about the case when you want to pass function > > arguments before a function call, not in a function prologue which is > a > > different story. > > > > In x86 it would be something like: > > > > sub esp, 8 > > mov DWORD PTR [esp], reg1 > > mov DWORD PTR [esp+4], reg 2 > > call foo > > ... > > > > instead of > > > > push reg1 > > push reg2 > > call foo > > ... > > > > which saves 1 instruction, but in our case doing "sub esp, 8" means > adding > > 5 or 6 more instructions. > > > > My x86 assembly is extremely rusty. ;-) > > Maybe we should work with a real test case... Do you have something that > shows the issue? > > Eric > > > |
|
From: Weddington, E. <Eri...@at...> - 2012-01-12 20:49:02
|
> -----Original Message----- > From: Borja Ferrer [mailto:bor...@gm...] > Sent: Thursday, January 12, 2012 1:25 PM > To: Weddington, Eric > Cc: Sherard Dames; avr...@li... > Subject: Re: [avr-llvm-devel] Current Status? > > For now I've implemented it the same way as gcc, but it's something that > popped to me when i was coding it. > I don't see how it saves space :) what I think is that you get the same > amount of pushes and std's when moving data into the stack no matter what > method is used. The difference I see is that when using std, you have to > adjust the SP pointer which creates an additional overhead. Just to > clarify I'm talking about the case when you want to pass function > arguments before a function call, not in a function prologue which is a > different story. > > In x86 it would be something like: > > sub esp, 8 > mov DWORD PTR [esp], reg1 > mov DWORD PTR [esp+4], reg 2 > call foo > ... > > instead of > > push reg1 > push reg2 > call foo > ... > > which saves 1 instruction, but in our case doing "sub esp, 8" means adding > 5 or 6 more instructions. > My x86 assembly is extremely rusty. ;-) Maybe we should work with a real test case... Do you have something that shows the issue? Eric |
|
From: Borja F. <bor...@gm...> - 2012-01-12 20:24:50
|
For now I've implemented it the same way as gcc, but it's something that popped to me when i was coding it. I don't see how it saves space :) what I think is that you get the same amount of pushes and std's when moving data into the stack no matter what method is used. The difference I see is that when using std, you have to adjust the SP pointer which creates an additional overhead. Just to clarify I'm talking about the case when you want to pass function arguments before a function call, not in a function prologue which is a different story. In x86 it would be something like: sub esp, 8 mov DWORD PTR [esp], reg1 mov DWORD PTR [esp+4], reg 2 call foo ... instead of push reg1 push reg2 call foo ... which saves 1 instruction, but in our case doing "sub esp, 8" means adding 5 or 6 more instructions. 2012/1/12 Weddington, Eric <Eri...@at...> > > > -----Original Message----- > > From: Borja Ferrer [mailto:bor...@gm...] > > Sent: Thursday, January 12, 2012 10:14 AM > > To: Weddington, Eric > > Cc: Sherard Dames; avr...@li... > > Subject: Re: [avr-llvm-devel] Current Status? > > > > Eric I have one question, when passing function parameters through the > > stack, why does gcc allocate stack space doing the typical copy from > SP to > > a reg, decrement it for the needed amount and then copy it back to SP > and > > then use std instructions, instead of directly pushing the registers > > saving all the SP manipulation? > > Is there particular reason for not doing this? > > > > I can only speculate on why GCC does that, and that would be to probably > save on code space. It depends (or, at least, it *should* depend) on how > much data is being passed as parameters. It might be smaller to do: > 1. copy SP to reg > 2. decrement reg by needed amount > 3. copy reg back to SP > than it would be to do multiple pushes. > > But, again, I stress that I'm just speculating as to why it would be the > case. > > For llvm, I would suggest that you do as you see fit, as long as it's > *correct* code, and then let's go back later to optimize it. If you > think it is easier to deal with doing all pushes, then go ahead and > implement it. Then we'll look at the code output. > > Eric Weddington > |
|
From: Weddington, E. <Eri...@at...> - 2012-01-12 19:56:58
|
> -----Original Message----- > From: Borja Ferrer [mailto:bor...@gm...] > Sent: Thursday, January 12, 2012 10:14 AM > To: Weddington, Eric > Cc: Sherard Dames; avr...@li... > Subject: Re: [avr-llvm-devel] Current Status? > > Eric I have one question, when passing function parameters through the > stack, why does gcc allocate stack space doing the typical copy from SP to > a reg, decrement it for the needed amount and then copy it back to SP and > then use std instructions, instead of directly pushing the registers > saving all the SP manipulation? > Is there particular reason for not doing this? > I can only speculate on why GCC does that, and that would be to probably save on code space. It depends (or, at least, it *should* depend) on how much data is being passed as parameters. It might be smaller to do: 1. copy SP to reg 2. decrement reg by needed amount 3. copy reg back to SP than it would be to do multiple pushes. But, again, I stress that I'm just speculating as to why it would be the case. For llvm, I would suggest that you do as you see fit, as long as it's *correct* code, and then let's go back later to optimize it. If you think it is easier to deal with doing all pushes, then go ahead and implement it. Then we'll look at the code output. Eric Weddington |
|
From: Borja F. <bor...@gm...> - 2012-01-12 17:14:27
|
Eric I have one question, when passing function parameters through the stack, why does gcc allocate stack space doing the typical copy from SP to a reg, decrement it for the needed amount and then copy it back to SP and then use std instructions, instead of directly pushing the registers saving all the SP manipulation? Is there particular reason for not doing this? 2012/1/11 Weddington, Eric <Eri...@at...> > > Unfortunately, I don't know of a document that describes that layout. > > Probably the best bet would be to look at the GNU Binutils source code > at the AVR backend. That source is about the best documentation we have. > > Eric Weddington > > > -----Original Message----- > > From: Borja Ferrer [mailto:bor...@gm...] > > Sent: Wednesday, January 11, 2012 3:03 PM > > To: Sherard Dames > > Cc: avr...@li... > > Subject: Re: [avr-llvm-devel] Current Status? > > > > I can't really say, maybe Eric can help here. What I use to develope > the > > backend is a pdf of the instruction set, but it doesnt specify what > > devices are supported for each instruction. > > > > > > 2012/1/11 Sherard Dames <sc...@gm...> > > > > > > Thanks for responding Borja. I do have a question, posed to > everyone > > really. Does anyone know where I can find a reference for which > > instructions are available for which AVR architectures? Haven't > been > > able to stumble upon one in my searches. > > > > Thanks, > > > > > > On Tue, 2012-01-10 at 17:35 +0100, Borja Ferrer wrote: > > > Hello everybody, > > > > > > Sorry about the delay of my reply, but I'm very busy this > month > > with > > > my finals. First thing I would like to say is to welcome > Sherard. > > As a > > > short summary, the current status to answer Sherard's question > is: > > > > > > Basically most of what is required to compile sequential code > (no > > > jumps) is implemented, this includes all memory addressing > modes, > > > arithmetic instructions, function calls, passing arguments, > etc. > > Last > > > thing I finished working on before Christmas was frames and > stack > > > manipulation. So we can now allocate automatic variables on > the > > stack, > > > pass arguments using the stack, and spill registers. > > > Next thing I'm going to work on are jumps and conditional > code, > > I'll > > > head into this in February when I'm done with my finals, I > only > > had > > > time to implement the jmp instruction which was pretty fast to > do, > > but > > > conditional code requires a lot more of work. > > > > > > Please don't look or work on any code in SVN because that is > going > > to > > > be removed, and I doubt it even compiles with the latest LLVM > > release. > > > It's my fault because i haven't uploaded yet any of the work > I've > > done > > > out of trunk to SVN but i want to have something in shape > before > > > commiting it, I think I will do it once conditional code is > done. > > > Looking in SVN is misleading because it looks as the project > is > > dead, > > > but that is totally wrong because we're getting a lot done out > of > > > there. > > > > > > About patches, I would say most of them are updated, I > commited a > > > patch some weeks ago for the register allocator, but if you > want > > to > > > check them it's ok. Related to code, i think patches are the > only > > > useful thing SVN has now, the backend code will go away. > > > > > > Since the LLVM backend code is not yet commited, I would > suggest > > as > > > John said working on regression tests, we're going to need > this > > soon, > > > and we're getting behind on this because we need a good test > suite > > to > > > catch as many errors as possible, so patches there are > welcome. > > > Something similar to what the MSP430 backend has would be a > decent > > > start. Tests related to arithmetic ops, function calls, > testing > > ABI, > > > and other things you can think of that dont require jumps. > > > Also on the other side, a lot of work is needed in Clang, we > need > > to > > > support many of the custom extensions AVR has like address > spaces > > or > > > interrupt handlers, so work is needed there aswell. We > discussed > > some > > > months ago about how to deal with address spaces but we didnt > > reach to > > > any formal decisions, so if you want to work on that aswell > you're > > > welcome. In fact, if you want to work both with tests and this > > that > > > would be great :) > > > > > > Another thing, I've noticed that the new register allocator in > 3.0 > > > uses less stack memory than IAR or GCC so that is something > > positive. > > > I see a lot of potential in getting better code than gcc in > the > > > future, because with the current generated code which is not > > optimized > > > at all (i want to leave that for a later stage) we're getting > in > > par > > > or improving what gcc does and sometimes getting a bit longer > code > > but > > > nothing that is too bad to worry. But once we introduce custom > > patters > > > for instruction selection things will improve exponentially. > > > > > > If you want to ask any specific questions after this general > > summary? > > > > > > ------------------------------------------------------------------ > > ------------ > > > Write once. Port to many. > > > Get the SDK and tools to simplify cross-platform app > development. > > Create > > > new or port existing apps to sell to consumers worldwide. > Explore > > the > > > Intel AppUpSM program developer opportunity. > > appdeveloper.intel.com/join > > > http://p.sf.net/sfu/intel-appdev > > > _______________________________________________ avr-llvm-devel > > mailing list avr...@li... > > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel > > > > > > > > > > |
|
From: Weddington, E. <Eri...@at...> - 2012-01-11 22:24:54
|
Unfortunately, I don't know of a document that describes that layout. Probably the best bet would be to look at the GNU Binutils source code at the AVR backend. That source is about the best documentation we have. Eric Weddington > -----Original Message----- > From: Borja Ferrer [mailto:bor...@gm...] > Sent: Wednesday, January 11, 2012 3:03 PM > To: Sherard Dames > Cc: avr...@li... > Subject: Re: [avr-llvm-devel] Current Status? > > I can't really say, maybe Eric can help here. What I use to develope the > backend is a pdf of the instruction set, but it doesnt specify what > devices are supported for each instruction. > > > 2012/1/11 Sherard Dames <sc...@gm...> > > > Thanks for responding Borja. I do have a question, posed to everyone > really. Does anyone know where I can find a reference for which > instructions are available for which AVR architectures? Haven't been > able to stumble upon one in my searches. > > Thanks, > > > On Tue, 2012-01-10 at 17:35 +0100, Borja Ferrer wrote: > > Hello everybody, > > > > Sorry about the delay of my reply, but I'm very busy this month > with > > my finals. First thing I would like to say is to welcome Sherard. > As a > > short summary, the current status to answer Sherard's question is: > > > > Basically most of what is required to compile sequential code (no > > jumps) is implemented, this includes all memory addressing modes, > > arithmetic instructions, function calls, passing arguments, etc. > Last > > thing I finished working on before Christmas was frames and stack > > manipulation. So we can now allocate automatic variables on the > stack, > > pass arguments using the stack, and spill registers. > > Next thing I'm going to work on are jumps and conditional code, > I'll > > head into this in February when I'm done with my finals, I only > had > > time to implement the jmp instruction which was pretty fast to do, > but > > conditional code requires a lot more of work. > > > > Please don't look or work on any code in SVN because that is going > to > > be removed, and I doubt it even compiles with the latest LLVM > release. > > It's my fault because i haven't uploaded yet any of the work I've > done > > out of trunk to SVN but i want to have something in shape before > > commiting it, I think I will do it once conditional code is done. > > Looking in SVN is misleading because it looks as the project is > dead, > > but that is totally wrong because we're getting a lot done out of > > there. > > > > About patches, I would say most of them are updated, I commited a > > patch some weeks ago for the register allocator, but if you want > to > > check them it's ok. Related to code, i think patches are the only > > useful thing SVN has now, the backend code will go away. > > > > Since the LLVM backend code is not yet commited, I would suggest > as > > John said working on regression tests, we're going to need this > soon, > > and we're getting behind on this because we need a good test suite > to > > catch as many errors as possible, so patches there are welcome. > > Something similar to what the MSP430 backend has would be a decent > > start. Tests related to arithmetic ops, function calls, testing > ABI, > > and other things you can think of that dont require jumps. > > Also on the other side, a lot of work is needed in Clang, we need > to > > support many of the custom extensions AVR has like address spaces > or > > interrupt handlers, so work is needed there aswell. We discussed > some > > months ago about how to deal with address spaces but we didnt > reach to > > any formal decisions, so if you want to work on that aswell you're > > welcome. In fact, if you want to work both with tests and this > that > > would be great :) > > > > Another thing, I've noticed that the new register allocator in 3.0 > > uses less stack memory than IAR or GCC so that is something > positive. > > I see a lot of potential in getting better code than gcc in the > > future, because with the current generated code which is not > optimized > > at all (i want to leave that for a later stage) we're getting in > par > > or improving what gcc does and sometimes getting a bit longer code > but > > nothing that is too bad to worry. But once we introduce custom > patters > > for instruction selection things will improve exponentially. > > > > If you want to ask any specific questions after this general > summary? > > > ------------------------------------------------------------------ > ------------ > > Write once. Port to many. > > Get the SDK and tools to simplify cross-platform app development. > Create > > new or port existing apps to sell to consumers worldwide. Explore > the > > Intel AppUpSM program developer opportunity. > appdeveloper.intel.com/join > > http://p.sf.net/sfu/intel-appdev > > _______________________________________________ avr-llvm-devel > mailing list avr...@li... > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel > > > > |
|
From: Borja F. <bor...@gm...> - 2012-01-11 22:03:19
|
I can't really say, maybe Eric can help here. What I use to develope the backend is a pdf of the instruction set, but it doesnt specify what devices are supported for each instruction. 2012/1/11 Sherard Dames <sc...@gm...> > Thanks for responding Borja. I do have a question, posed to everyone > really. Does anyone know where I can find a reference for which > instructions are available for which AVR architectures? Haven't been > able to stumble upon one in my searches. > > Thanks, > > On Tue, 2012-01-10 at 17:35 +0100, Borja Ferrer wrote: > > Hello everybody, > > > > Sorry about the delay of my reply, but I'm very busy this month with > > my finals. First thing I would like to say is to welcome Sherard. As a > > short summary, the current status to answer Sherard's question is: > > > > Basically most of what is required to compile sequential code (no > > jumps) is implemented, this includes all memory addressing modes, > > arithmetic instructions, function calls, passing arguments, etc. Last > > thing I finished working on before Christmas was frames and stack > > manipulation. So we can now allocate automatic variables on the stack, > > pass arguments using the stack, and spill registers. > > Next thing I'm going to work on are jumps and conditional code, I'll > > head into this in February when I'm done with my finals, I only had > > time to implement the jmp instruction which was pretty fast to do, but > > conditional code requires a lot more of work. > > > > Please don't look or work on any code in SVN because that is going to > > be removed, and I doubt it even compiles with the latest LLVM release. > > It's my fault because i haven't uploaded yet any of the work I've done > > out of trunk to SVN but i want to have something in shape before > > commiting it, I think I will do it once conditional code is done. > > Looking in SVN is misleading because it looks as the project is dead, > > but that is totally wrong because we're getting a lot done out of > > there. > > > > About patches, I would say most of them are updated, I commited a > > patch some weeks ago for the register allocator, but if you want to > > check them it's ok. Related to code, i think patches are the only > > useful thing SVN has now, the backend code will go away. > > > > Since the LLVM backend code is not yet commited, I would suggest as > > John said working on regression tests, we're going to need this soon, > > and we're getting behind on this because we need a good test suite to > > catch as many errors as possible, so patches there are welcome. > > Something similar to what the MSP430 backend has would be a decent > > start. Tests related to arithmetic ops, function calls, testing ABI, > > and other things you can think of that dont require jumps. > > Also on the other side, a lot of work is needed in Clang, we need to > > support many of the custom extensions AVR has like address spaces or > > interrupt handlers, so work is needed there aswell. We discussed some > > months ago about how to deal with address spaces but we didnt reach to > > any formal decisions, so if you want to work on that aswell you're > > welcome. In fact, if you want to work both with tests and this that > > would be great :) > > > > Another thing, I've noticed that the new register allocator in 3.0 > > uses less stack memory than IAR or GCC so that is something positive. > > I see a lot of potential in getting better code than gcc in the > > future, because with the current generated code which is not optimized > > at all (i want to leave that for a later stage) we're getting in par > > or improving what gcc does and sometimes getting a bit longer code but > > nothing that is too bad to worry. But once we introduce custom patters > > for instruction selection things will improve exponentially. > > > > If you want to ask any specific questions after this general summary? > > > ------------------------------------------------------------------------------ > > Write once. Port to many. > > Get the SDK and tools to simplify cross-platform app development. Create > > new or port existing apps to sell to consumers worldwide. Explore the > > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join > > http://p.sf.net/sfu/intel-appdev > > _______________________________________________ avr-llvm-devel mailing > list avr...@li... > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel > > > |
|
From: Sherard D. <sc...@gm...> - 2012-01-11 20:17:08
|
Thanks for responding Borja. I do have a question, posed to everyone really. Does anyone know where I can find a reference for which instructions are available for which AVR architectures? Haven't been able to stumble upon one in my searches. Thanks, On Tue, 2012-01-10 at 17:35 +0100, Borja Ferrer wrote: > Hello everybody, > > Sorry about the delay of my reply, but I'm very busy this month with > my finals. First thing I would like to say is to welcome Sherard. As a > short summary, the current status to answer Sherard's question is: > > Basically most of what is required to compile sequential code (no > jumps) is implemented, this includes all memory addressing modes, > arithmetic instructions, function calls, passing arguments, etc. Last > thing I finished working on before Christmas was frames and stack > manipulation. So we can now allocate automatic variables on the stack, > pass arguments using the stack, and spill registers. > Next thing I'm going to work on are jumps and conditional code, I'll > head into this in February when I'm done with my finals, I only had > time to implement the jmp instruction which was pretty fast to do, but > conditional code requires a lot more of work. > > Please don't look or work on any code in SVN because that is going to > be removed, and I doubt it even compiles with the latest LLVM release. > It's my fault because i haven't uploaded yet any of the work I've done > out of trunk to SVN but i want to have something in shape before > commiting it, I think I will do it once conditional code is done. > Looking in SVN is misleading because it looks as the project is dead, > but that is totally wrong because we're getting a lot done out of > there. > > About patches, I would say most of them are updated, I commited a > patch some weeks ago for the register allocator, but if you want to > check them it's ok. Related to code, i think patches are the only > useful thing SVN has now, the backend code will go away. > > Since the LLVM backend code is not yet commited, I would suggest as > John said working on regression tests, we're going to need this soon, > and we're getting behind on this because we need a good test suite to > catch as many errors as possible, so patches there are welcome. > Something similar to what the MSP430 backend has would be a decent > start. Tests related to arithmetic ops, function calls, testing ABI, > and other things you can think of that dont require jumps. > Also on the other side, a lot of work is needed in Clang, we need to > support many of the custom extensions AVR has like address spaces or > interrupt handlers, so work is needed there aswell. We discussed some > months ago about how to deal with address spaces but we didnt reach to > any formal decisions, so if you want to work on that aswell you're > welcome. In fact, if you want to work both with tests and this that > would be great :) > > Another thing, I've noticed that the new register allocator in 3.0 > uses less stack memory than IAR or GCC so that is something positive. > I see a lot of potential in getting better code than gcc in the > future, because with the current generated code which is not optimized > at all (i want to leave that for a later stage) we're getting in par > or improving what gcc does and sometimes getting a bit longer code but > nothing that is too bad to worry. But once we introduce custom patters > for instruction selection things will improve exponentially. > > If you want to ask any specific questions after this general summary? > ------------------------------------------------------------------------------ > Write once. Port to many. > Get the SDK and tools to simplify cross-platform app development. Create > new or port existing apps to sell to consumers worldwide. Explore the > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join > http://p.sf.net/sfu/intel-appdev > _______________________________________________ avr-llvm-devel mailing list avr...@li... https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel |
|
From: Borja F. <bor...@gm...> - 2012-01-10 16:36:06
|
Hello everybody, Sorry about the delay of my reply, but I'm very busy this month with my finals. First thing I would like to say is to welcome Sherard. As a short summary, the current status to answer Sherard's question is: Basically most of what is required to compile sequential code (no jumps) is implemented, this includes all memory addressing modes, arithmetic instructions, function calls, passing arguments, etc. Last thing I finished working on before Christmas was frames and stack manipulation. So we can now allocate automatic variables on the stack, pass arguments using the stack, and spill registers. Next thing I'm going to work on are jumps and conditional code, I'll head into this in February when I'm done with my finals, I only had time to implement the jmp instruction which was pretty fast to do, but conditional code requires a lot more of work. Please don't look or work on any code in SVN because that is going to be removed, and I doubt it even compiles with the latest LLVM release. It's my fault because i haven't uploaded yet any of the work I've done out of trunk to SVN but i want to have something in shape before commiting it, I think I will do it once conditional code is done. Looking in SVN is misleading because it looks as the project is dead, but that is totally wrong because we're getting a lot done out of there. About patches, I would say most of them are updated, I commited a patch some weeks ago for the register allocator, but if you want to check them it's ok. Related to code, i think patches are the only useful thing SVN has now, the backend code will go away. Since the LLVM backend code is not yet commited, I would suggest as John said working on regression tests, we're going to need this soon, and we're getting behind on this because we need a good test suite to catch as many errors as possible, so patches there are welcome. Something similar to what the MSP430 backend has would be a decent start. Tests related to arithmetic ops, function calls, testing ABI, and other things you can think of that dont require jumps. Also on the other side, a lot of work is needed in Clang, we need to support many of the custom extensions AVR has like address spaces or interrupt handlers, so work is needed there aswell. We discussed some months ago about how to deal with address spaces but we didnt reach to any formal decisions, so if you want to work on that aswell you're welcome. In fact, if you want to work both with tests and this that would be great :) Another thing, I've noticed that the new register allocator in 3.0 uses less stack memory than IAR or GCC so that is something positive. I see a lot of potential in getting better code than gcc in the future, because with the current generated code which is not optimized at all (i want to leave that for a later stage) we're getting in par or improving what gcc does and sometimes getting a bit longer code but nothing that is too bad to worry. But once we introduce custom patters for instruction selection things will improve exponentially. If you want to ask any specific questions after this general summary? |
|
From: John M. <ato...@gm...> - 2012-01-04 06:59:56
|
On Tue, Jan 3, 2012 at 8:05 PM, Sherard Dames <sc...@gm...> wrote: > John, > > I've looked into writing more test cases. It seems that the LLVM > regression testing system is incredibly easy to use, and I've already > mocked up a few tests with it. Are there any specific things I should > have in mind when writing tests? > > Borja would have a better idea of which tests are needed now. The MSP430 target (llvm/test/CodeGen/MSP430) may be helpful as an example. I think we'll basically need tests for each asm instruction to start with. Also test that show the avr-gcc ABI works properly (calls, returns, stack pointer...). Also thinks like auto, global, static, and volatile variables. > Will soon take a look at bringing the patches up to date with the LLVM > trunk. (I assume we're talking about those in the > svn /llvm/trunk/patches/) > > Yeah, and also the clang patches (cfe/trunk/patches). > As for DragonEgg, not sure I understand it. From what basic research I > did on it, I didn't find a whole lot of documentation but from what I > gathered so far I'm not sure I see the benefits. The most obvious > benefit I could see was to leverage GCC's existing AVR support instead > of patching clang. However to me that just seems like shifting effort > from one place to another (clang to DragonEgg) to get (essentially) the > same result. That idea aside, as far as I'm aware, clang already tries > to be very compatible with GCC. Additionally Windows does not seem to be > on that list of "successfully used on" platforms for DragonEgg, and I > might be wrong about this, but I thought Windows was the most common > development platform for the AVR? What is it that I'm missing here? > > Basically it allows people to use the avr-gcc compiler and still get the advantages of the llvm backend's code generation and optimization. Personally I would prefer working on only Clang. I have a feeling though we'll need DragonEgg to get people to transition over to CLANG/LLVM. I'm more then happy to be wrong though. There was (is?) an issue with windows dll's and the gcc plugin interface. I read that there was a fix in the works though. Yeah, Clang is designed to be a drop in replacement (minus a few purposeful exceptions) for gcc. |
|
From: Sherard D. <sc...@gm...> - 2012-01-04 04:06:06
|
John, I've looked into writing more test cases. It seems that the LLVM regression testing system is incredibly easy to use, and I've already mocked up a few tests with it. Are there any specific things I should have in mind when writing tests? Will soon take a look at bringing the patches up to date with the LLVM trunk. (I assume we're talking about those in the svn /llvm/trunk/patches/) As for DragonEgg, not sure I understand it. From what basic research I did on it, I didn't find a whole lot of documentation but from what I gathered so far I'm not sure I see the benefits. The most obvious benefit I could see was to leverage GCC's existing AVR support instead of patching clang. However to me that just seems like shifting effort from one place to another (clang to DragonEgg) to get (essentially) the same result. That idea aside, as far as I'm aware, clang already tries to be very compatible with GCC. Additionally Windows does not seem to be on that list of "successfully used on" platforms for DragonEgg, and I might be wrong about this, but I thought Windows was the most common development platform for the AVR? What is it that I'm missing here? Thanks, -----Original Message----- From: John Myers <ato...@gm...> To: Sherard Dames <sc...@gm...> Cc: avr...@li... Subject: Re: [avr-llvm-devel] Current Status? Date: Sun, 1 Jan 2012 23:46:08 -0800 Hi Sherard, Borja was working on a re-write of the llvm code. What's in llvm trunk now has a lot of bit-rot so spending too much time on it before the new code is committed would be a waste. Borja's mentioned we need more test cases to spot regressions. We have some test cases but they're not organized or in the format that the LLVM tools use. So one helpful thing would be to create/document/organize test cases and then also make them work with the LLVM regression test system. There's also plenty of work for the Clang and Dragonegg front ends. Dragonegg [http://dragonegg.llvm.org/] is the gcc front end. There will probable be a lot of people who will prefer to tryout LLVM through the more gradual transition via Dragonegg. I've added some skeleton files but basically nothing been done with Dragonegg. So creating an AVR-Dragonegg port is needed. Building/testing an avr-gcc version that works with plugins (aka Dragonegg) also needs to be done. I believe avr-gcc needs to be compiled to support LTO and plugins. Getting the avr patches to apply cleanly to the current LLVM trunk probable is needed also. This should be simple task. Thanks, John On Fri, Dec 30, 2011 at 4:11 PM, Sherard Dames <sc...@gm...> wrote: Hi Eric, I am interested in an AVR backend for LLVM, so naturally I stumbled across this project. So I suppose my interest would be contribution as I have quite a bit of time on my hands, and would like to see it happen. I have been hacking away to get my hands dirty with LLVM, as I am unfamiliar with it. Ultimately I was hoping to contribute to a pre-existing effort, and I would like to get started here. I would appreciate some guidance as to some goals that I could begin helping around with, as I'm not sure about the status of the code in the SVN repository (or what's "safe" to work on). I'm very interested in getting this project moving a bit more. Thanks, On Thu, 2011-12-29 at 22:28 -0700, Weddington, Eric wrote: > Hi Sherard, > > No, it's not a dead project. However, it is a slow-moving project. :-) > > There are some behind-the-scenes work going on by a couple of the > developers. But this does not mean "behind close doors". It's usually > sporadic work that is going on, that is not yet committed, usually due > to developer time constraints. > > If I may ask, what is your interest in the project? > > Thanks, > Eric Weddington > > > -----Original Message----- > > From: Sherard Dames [mailto:sc...@gm...] > > Sent: Thursday, December 29, 2011 12:14 PM > > To: avr...@li... > > Subject: [avr-llvm-devel] Current Status? > > > > Hello everyone, > > > > I'm curious as to the current status of this project. From the looks > of > > the SVN (and the mailing list) it would appear that the project is > > fairly inactive. Is it simply that work is going on behind closed > doors? > > Or perhaps, is it a dead project? > > > > > > > > > > > ------------------------------------------------------------------------ > -- > > ---- > > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a > complex > > infrastructure or vast IT resources to deliver seamless, secure access > to > > virtual desktops. With this all-in-one solution, easily deploy virtual > > desktops for less than the cost of PCs and save 60% on VDI > infrastructure > > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > > _______________________________________________ > > avr-llvm-devel mailing list > > avr...@li... > > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ avr-llvm-devel mailing list avr...@li... https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel |
|
From: John M. <ato...@gm...> - 2012-01-02 07:46:16
|
Hi Sherard, Borja was working on a re-write of the llvm code. What's in llvm trunk now has a lot of bit-rot so spending too much time on it before the new code is committed would be a waste. Borja's mentioned we need more test cases to spot regressions. We have some test cases but they're not organized or in the format that the LLVM tools use.* So one helpful thing would be to create/document/organize test cases and then also make them work with the LLVM regression test system. * There's also plenty of work for the Clang and Dragonegg front ends. Dragonegg [http://dragonegg.llvm.org/] is the gcc front end. There will probable be a lot of people who will prefer to tryout LLVM through the more gradual transition via Dragonegg. I've added some skeleton files but basically nothing been done with Dragonegg. *So creating an AVR-Dragonegg port is needed.* *Building/testing an avr-gcc version that works with plugins (aka Dragonegg) also needs to be done.* I believe avr-gcc needs to be compiled to support LTO and plugins. *Getting the avr patches to apply cleanly to the current LLVM trunk probable is needed also.* This should be simple task. Thanks, John On Fri, Dec 30, 2011 at 4:11 PM, Sherard Dames <sc...@gm...> wrote: > Hi Eric, > > I am interested in an AVR backend for LLVM, so naturally I stumbled > across this project. So I suppose my interest would be contribution as I > have quite a bit of time on my hands, and would like to see it happen. > > I have been hacking away to get my hands dirty with LLVM, as I am > unfamiliar with it. Ultimately I was hoping to contribute to a > pre-existing effort, and I would like to get started here. > > I would appreciate some guidance as to some goals that I could begin > helping around with, as I'm not sure about the status of the code in the > SVN repository (or what's "safe" to work on). I'm very interested in > getting this project moving a bit more. > > Thanks, > > > > On Thu, 2011-12-29 at 22:28 -0700, Weddington, Eric wrote: > > Hi Sherard, > > > > No, it's not a dead project. However, it is a slow-moving project. :-) > > > > There are some behind-the-scenes work going on by a couple of the > > developers. But this does not mean "behind close doors". It's usually > > sporadic work that is going on, that is not yet committed, usually due > > to developer time constraints. > > > > If I may ask, what is your interest in the project? > > > > Thanks, > > Eric Weddington > > > > > -----Original Message----- > > > From: Sherard Dames [mailto:sc...@gm...] > > > Sent: Thursday, December 29, 2011 12:14 PM > > > To: avr...@li... > > > Subject: [avr-llvm-devel] Current Status? > > > > > > Hello everyone, > > > > > > I'm curious as to the current status of this project. From the looks > > of > > > the SVN (and the mailing list) it would appear that the project is > > > fairly inactive. Is it simply that work is going on behind closed > > doors? > > > Or perhaps, is it a dead project? > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > -- > > > ---- > > > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a > > complex > > > infrastructure or vast IT resources to deliver seamless, secure access > > to > > > virtual desktops. With this all-in-one solution, easily deploy virtual > > > desktops for less than the cost of PCs and save 60% on VDI > > infrastructure > > > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > > > _______________________________________________ > > > avr-llvm-devel mailing list > > > avr...@li... > > > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel > > > > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > avr-llvm-devel mailing list > avr...@li... > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel > |
|
From: Sherard D. <sc...@gm...> - 2011-12-31 00:11:24
|
Hi Eric, I am interested in an AVR backend for LLVM, so naturally I stumbled across this project. So I suppose my interest would be contribution as I have quite a bit of time on my hands, and would like to see it happen. I have been hacking away to get my hands dirty with LLVM, as I am unfamiliar with it. Ultimately I was hoping to contribute to a pre-existing effort, and I would like to get started here. I would appreciate some guidance as to some goals that I could begin helping around with, as I'm not sure about the status of the code in the SVN repository (or what's "safe" to work on). I'm very interested in getting this project moving a bit more. Thanks, On Thu, 2011-12-29 at 22:28 -0700, Weddington, Eric wrote: > Hi Sherard, > > No, it's not a dead project. However, it is a slow-moving project. :-) > > There are some behind-the-scenes work going on by a couple of the > developers. But this does not mean "behind close doors". It's usually > sporadic work that is going on, that is not yet committed, usually due > to developer time constraints. > > If I may ask, what is your interest in the project? > > Thanks, > Eric Weddington > > > -----Original Message----- > > From: Sherard Dames [mailto:sc...@gm...] > > Sent: Thursday, December 29, 2011 12:14 PM > > To: avr...@li... > > Subject: [avr-llvm-devel] Current Status? > > > > Hello everyone, > > > > I'm curious as to the current status of this project. From the looks > of > > the SVN (and the mailing list) it would appear that the project is > > fairly inactive. Is it simply that work is going on behind closed > doors? > > Or perhaps, is it a dead project? > > > > > > > > > > > ------------------------------------------------------------------------ > -- > > ---- > > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a > complex > > infrastructure or vast IT resources to deliver seamless, secure access > to > > virtual desktops. With this all-in-one solution, easily deploy virtual > > desktops for less than the cost of PCs and save 60% on VDI > infrastructure > > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > > _______________________________________________ > > avr-llvm-devel mailing list > > avr...@li... > > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel |
|
From: Weddington, E. <Eri...@at...> - 2011-12-30 05:57:12
|
Hi Sherard, No, it's not a dead project. However, it is a slow-moving project. :-) There are some behind-the-scenes work going on by a couple of the developers. But this does not mean "behind close doors". It's usually sporadic work that is going on, that is not yet committed, usually due to developer time constraints. If I may ask, what is your interest in the project? Thanks, Eric Weddington > -----Original Message----- > From: Sherard Dames [mailto:sc...@gm...] > Sent: Thursday, December 29, 2011 12:14 PM > To: avr...@li... > Subject: [avr-llvm-devel] Current Status? > > Hello everyone, > > I'm curious as to the current status of this project. From the looks of > the SVN (and the mailing list) it would appear that the project is > fairly inactive. Is it simply that work is going on behind closed doors? > Or perhaps, is it a dead project? > > > > > ------------------------------------------------------------------------ -- > ---- > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > avr-llvm-devel mailing list > avr...@li... > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel |
14 messages has been excluded from this view by a project administrator.
