avr-llvm-devel — Developers mailing list.

Re: [avr-llvm-devel] Regression tests

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

Nice to see you around Eric :)

Indeed, things are getting zero extended and then truncated back, there are
two things going on here. First is that I'm getting things converted to i16
instead of i32, did you patch clang? I'll have to check if the target patch
stuff of clang is right. Second is that I dont have the zeroext attribute
and that's my fault because it's a patch for clang that I haven't commited.

The type promotion is something in the C standard and because sizeof(int)
is bigger than a register things get a bit nasty, but it's valid code.

2012/4/30 Nicklas Bo Jensen <nbj...@gm...>

> I'm using clang.
>
> define zeroext i8 @add() nounwind uwtable {
>   %a = alloca i8, align 1
>   %b = alloca i8, align 1
>   store i8 5, i8* %a, align 1
>   store i8 7, i8* %b, align 1
>   %1 = load i8* %a, align 1
>   %2 = zext i8 %1 to i32
>   %3 = load i8* %b, align 1
>   %4 = zext i8 %3 to i32
>   %5 = add nsw i32 %2, %4
>   %6 = trunc i32 %5 to i8
>   ret i8 %6
> }
>
> On Mon, Apr 30, 2012 at 8:22 PM, Borja Ferrer <bor...@gm...>wrote:
>
>> I see what's going here, our version is doing a 16bit addition and then
>> truncating it back to 8bits. Are you using clang or dragonegg for the
>> frontend? And can you post the llvm asm?
>> Also, no need to test imm+imm, only reg+imm and reg+reg will do, the
>> other will be constant folded.
>>
>> Ah, you'll need svn commit access, John or Eric could you do it?
>>
>>
>> 2012/4/30 Nicklas Bo Jensen <nbj...@gm...>
>>
>>> On Mon, Apr 30, 2012 at 12:33 AM, Borja Ferrer <bor...@gm...>
>>>  wrote:
>>>
>>>> It should be similar to what other backends do, in this case we should
>>>> test adding with 2 regs and then with immediates values, and repeat this
>>>> for each value type (i8, i16, i32 and i64). Checking the instruction itself
>>>> is enough, no need to check for registers aswell, that will come in other
>>>> tests. But when testing with imm values we should check that the imm value
>>>> is correctly generated, so in this case ignore the reg, but check that the
>>>> imm field is valid.
>>>>
>>>
>>> Ok, makes sense. I will work on creating the tests.
>>>
>>>
>>>> And what do you mean in that you get different code between gcc and
>>>> llvm?
>>>
>>>
>>> Basically if I compile:
>>>
>>> unsigned char add()
>>> {
>>>   unsigned char a,b;
>>>   a = 5;
>>>   b = 7;
>>>   return a+b;
>>> }
>>>
>>>
>>> with avr-gcc part of the resulting assembler is:
>>> ldi r24,lo8(5)
>>>  std Y+1,r24
>>> ldi r24,lo8(7)
>>> std Y+2,r24
>>> ldd r25,Y+1
>>>  ldd r24,Y+2
>>> add r24,r25
>>>
>>> with clang+avr-llvm part of the resulting assembler is:
>>>  ldi r24, 5
>>> std Y+2, r24
>>> ldi r24, 7
>>>  std Y+1, r24
>>> ldd r24, Y+2
>>>  adiw r25:r24, 7
>>> andi r24, 255
>>>  andi r25, 0
>>>
>>> So they use different approaches(add and adiw) to solve the same problem.
>>>
>>> Thanks
>>> Nicklas
>>>
>>> 2012/4/29 Nicklas Bo Jensen <nbj...@gm...>
>>>>
>>>>> Sure. Just wanted to actually compile the code before writing tests.
>>>>>
>>>>> Got how the test framework works and added a very small test that is
>>>>> working perfectly.
>>>>>
>>>>> How detailed should the test be? Should it check the generated
>>>>> assembly fully or just the main parts, e.g. the addition itself? For an
>>>>> addition the avr-llvm version is quite different from the avr-gcc version.
>>>>>
>>>>> Thanks,
>>>>> Nicklas
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Apr 29, 2012 at 8:07 PM, Borja Ferrer <bor...@gm...>wrote:
>>>>>
>>>>>> The problem here is that I've represented register pairs as r29:r28
>>>>>> while the assembler only wants the low register of the pair, that's why
>>>>>> you're getting that error but you're doing it right.
>>>>>>
>>>>>> But the way of writing regression tests in llvm is different to what
>>>>>> you're doing. Those tests in SVN are going away once we start writing the
>>>>>> new ones.
>>>>>>
>>>>>> Read this: http://llvm.org/docs/TestingGuide.html
>>>>>> and then go to
>>>>>> http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/ and
>>>>>> choose any target you wish (say msp430 since it's the most similar one to
>>>>>> us) to see how real tests look like.
>>>>>>
>>>>>> Basically, you have to write a test in llvm assembly, and then with
>>>>>> CHECK you write the avr assembly that should be emitted, if it matches then
>>>>>> the test passes otherwise it fails. You can avoid writing the llvm assembly
>>>>>> by writing the test in C and then translate it to llvm assembly with clang.
>>>>>>
>>>>>> Try writing a small test for add using the llvm testing
>>>>>> infrastructure and then run it with llvm to see if it passes.
>>>>>> It's very important that you write the expected output assembly
>>>>>> right, otherwise we'll generate wrong code to make the test pass, but since
>>>>>> tests are quite small it's easy to get it right.
>>>>>>
>>>>>>
>>>>>> 2012/4/29 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have successfully been able to compile your testcases
>>>>>>> (/avr-llvm/testcases/*.ll) to something looking like valid avr assembler.
>>>>>>>
>>>>>>> How should I test/simulate the assembler? I get errors when trying
>>>>>>> to simulate the generated assembler in AVRStudio. Perhaps they use a
>>>>>>> different assembler?
>>>>>>>
>>>>>>> For one test, add1.ll I cannot process it using avr-as. I have done:
>>>>>>>
>>>>>>> ../../build/Debug+Asserts/bin/llc --march=avr add1.ll -o add1.s
>>>>>>> avr-as -mmcu=atmega168 add1.s
>>>>>>>
>>>>>>>
>>>>>>> and get the error:
>>>>>>>
>>>>>>> asm.s: Assembler messages:
>>>>>>> asm.s:12: Error: register r24, r26, r28 or r30 required
>>>>>>> asm.s:12: Error: `,' required
>>>>>>> asm.s:12: Error: garbage at end of line
>>>>>>> asm.s:24: Error: register r24, r26, r28 or r30 required
>>>>>>> asm.s:24: Error: `,' required
>>>>>>> asm.s:24: Error: garbage at end of line
>>>>>>>
>>>>>>>
>>>>>>> Am I doing something wrong? I have included the assembler.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Nicklas
>>>>>>>
>>>>>>> On Sun, Apr 29, 2012 at 7:23 PM, Borja Ferrer <bor...@gm...
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> Hello Neil I'm replying you in this thread, i dont know why I
>>>>>>>> didn't receive your mail, i had to look in SF to read it.
>>>>>>>>
>>>>>>>> Anyways, first try to build the backend so you can play a bit with
>>>>>>>> it to get familiar with its code. Try compiling some C code to generate avr
>>>>>>>> assembly.
>>>>>>>>
>>>>>>>> 2012/4/23 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I'll be happy to contribute, after I have fixed my issues getting
>>>>>>>>> avr-llvm to compile in the first place.
>>>>>>>>>
>>>>>>>>> BR,
>>>>>>>>> Nicklas
>>>>>>>>>
>>>>>>>>> On Sun, Apr 22, 2012 at 7:26 PM, Borja Ferrer <
>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>
>>>>>>>>>> I think it's time to stop adding more features until we cover
>>>>>>>>>> what is currently implemented with regression tests. Otherwise the further
>>>>>>>>>> we go the harder will be to cover everything up, from now on it's going to
>>>>>>>>>> be easier to go in parallel.
>>>>>>>>>> In the past emails I've seen people interested in helping out
>>>>>>>>>> with this, it's a good way of starting with some development becuase it's
>>>>>>>>>> an easy task to do and it helps to understand how llvm works, so anybody
>>>>>>>>>> interested check in here so I know if I'm going to have any help at all or
>>>>>>>>>> I have to do it myself.
>>>>>>>>>>
>>>>>>>>>> So if there's some help available we can plan in this thread what
>>>>>>>>>> needs to get covered and how to do it, I'll wait a few days for any replies.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> For Developers, A Lot Can Happen In A Second.
>>>>>>>>>> Boundary is the first to Know...and Tell You.
>>>>>>>>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>>>>>>>>>> http://p.sf.net/sfu/Boundary-d2dvs2
>>>>>>>>>> _______________________________________________
>>>>>>>>>> avr-llvm-devel mailing list
>>>>>>>>>> avr...@li...
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Live Security Virtual Conference
>>>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>>>> threat landscape has changed and how IT managers can respond.
>>>>>>>> Discussions
>>>>>>>> will include endpoint security, mobile security and the latest in
>>>>>>>> malware
>>>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> avr-llvm-devel mailing list
>>>>>>>> avr...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [avr-llvm-devel] Regression tests

[Nicklas Bo J. <nbj...@gm...>]

I'm using clang.

define zeroext i8 @add() nounwind uwtable {
  %a = alloca i8, align 1
  %b = alloca i8, align 1
  store i8 5, i8* %a, align 1
  store i8 7, i8* %b, align 1
  %1 = load i8* %a, align 1
  %2 = zext i8 %1 to i32
  %3 = load i8* %b, align 1
  %4 = zext i8 %3 to i32
  %5 = add nsw i32 %2, %4
  %6 = trunc i32 %5 to i8
  ret i8 %6
}

On Mon, Apr 30, 2012 at 8:22 PM, Borja Ferrer <bor...@gm...> wrote:

> I see what's going here, our version is doing a 16bit addition and then
> truncating it back to 8bits. Are you using clang or dragonegg for the
> frontend? And can you post the llvm asm?
> Also, no need to test imm+imm, only reg+imm and reg+reg will do, the other
> will be constant folded.
>
> Ah, you'll need svn commit access, John or Eric could you do it?
>
>
> 2012/4/30 Nicklas Bo Jensen <nbj...@gm...>
>
>> On Mon, Apr 30, 2012 at 12:33 AM, Borja Ferrer <bor...@gm...>
>>  wrote:
>>
>>> It should be similar to what other backends do, in this case we should
>>> test adding with 2 regs and then with immediates values, and repeat this
>>> for each value type (i8, i16, i32 and i64). Checking the instruction itself
>>> is enough, no need to check for registers aswell, that will come in other
>>> tests. But when testing with imm values we should check that the imm value
>>> is correctly generated, so in this case ignore the reg, but check that the
>>> imm field is valid.
>>>
>>
>> Ok, makes sense. I will work on creating the tests.
>>
>>
>>> And what do you mean in that you get different code between gcc and llvm?
>>
>>
>> Basically if I compile:
>>
>> unsigned char add()
>> {
>>   unsigned char a,b;
>>   a = 5;
>>   b = 7;
>>   return a+b;
>> }
>>
>>
>> with avr-gcc part of the resulting assembler is:
>> ldi r24,lo8(5)
>>  std Y+1,r24
>> ldi r24,lo8(7)
>> std Y+2,r24
>> ldd r25,Y+1
>>  ldd r24,Y+2
>> add r24,r25
>>
>> with clang+avr-llvm part of the resulting assembler is:
>>  ldi r24, 5
>> std Y+2, r24
>> ldi r24, 7
>>  std Y+1, r24
>> ldd r24, Y+2
>>  adiw r25:r24, 7
>> andi r24, 255
>>  andi r25, 0
>>
>> So they use different approaches(add and adiw) to solve the same problem.
>>
>> Thanks
>> Nicklas
>>
>> 2012/4/29 Nicklas Bo Jensen <nbj...@gm...>
>>>
>>>> Sure. Just wanted to actually compile the code before writing tests.
>>>>
>>>> Got how the test framework works and added a very small test that is
>>>> working perfectly.
>>>>
>>>> How detailed should the test be? Should it check the generated assembly
>>>> fully or just the main parts, e.g. the addition itself? For an addition the
>>>> avr-llvm version is quite different from the avr-gcc version.
>>>>
>>>> Thanks,
>>>> Nicklas
>>>>
>>>>
>>>>
>>>> On Sun, Apr 29, 2012 at 8:07 PM, Borja Ferrer <bor...@gm...>wrote:
>>>>
>>>>> The problem here is that I've represented register pairs as r29:r28
>>>>> while the assembler only wants the low register of the pair, that's why
>>>>> you're getting that error but you're doing it right.
>>>>>
>>>>> But the way of writing regression tests in llvm is different to what
>>>>> you're doing. Those tests in SVN are going away once we start writing the
>>>>> new ones.
>>>>>
>>>>> Read this: http://llvm.org/docs/TestingGuide.html
>>>>> and then go to
>>>>> http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/ and
>>>>> choose any target you wish (say msp430 since it's the most similar one to
>>>>> us) to see how real tests look like.
>>>>>
>>>>> Basically, you have to write a test in llvm assembly, and then with
>>>>> CHECK you write the avr assembly that should be emitted, if it matches then
>>>>> the test passes otherwise it fails. You can avoid writing the llvm assembly
>>>>> by writing the test in C and then translate it to llvm assembly with clang.
>>>>>
>>>>> Try writing a small test for add using the llvm testing infrastructure
>>>>> and then run it with llvm to see if it passes.
>>>>> It's very important that you write the expected output assembly right,
>>>>> otherwise we'll generate wrong code to make the test pass, but since tests
>>>>> are quite small it's easy to get it right.
>>>>>
>>>>>
>>>>> 2012/4/29 Nicklas Bo Jensen <nbj...@gm...>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have successfully been able to compile your testcases
>>>>>> (/avr-llvm/testcases/*.ll) to something looking like valid avr assembler.
>>>>>>
>>>>>> How should I test/simulate the assembler? I get errors when trying to
>>>>>> simulate the generated assembler in AVRStudio. Perhaps they use a different
>>>>>> assembler?
>>>>>>
>>>>>> For one test, add1.ll I cannot process it using avr-as. I have done:
>>>>>>
>>>>>> ../../build/Debug+Asserts/bin/llc --march=avr add1.ll -o add1.s
>>>>>> avr-as -mmcu=atmega168 add1.s
>>>>>>
>>>>>>
>>>>>> and get the error:
>>>>>>
>>>>>> asm.s: Assembler messages:
>>>>>> asm.s:12: Error: register r24, r26, r28 or r30 required
>>>>>> asm.s:12: Error: `,' required
>>>>>> asm.s:12: Error: garbage at end of line
>>>>>> asm.s:24: Error: register r24, r26, r28 or r30 required
>>>>>> asm.s:24: Error: `,' required
>>>>>> asm.s:24: Error: garbage at end of line
>>>>>>
>>>>>>
>>>>>> Am I doing something wrong? I have included the assembler.
>>>>>>
>>>>>> Thanks,
>>>>>> Nicklas
>>>>>>
>>>>>> On Sun, Apr 29, 2012 at 7:23 PM, Borja Ferrer <bor...@gm...>wrote:
>>>>>>
>>>>>>> Hello Neil I'm replying you in this thread, i dont know why I didn't
>>>>>>> receive your mail, i had to look in SF to read it.
>>>>>>>
>>>>>>> Anyways, first try to build the backend so you can play a bit with
>>>>>>> it to get familiar with its code. Try compiling some C code to generate avr
>>>>>>> assembly.
>>>>>>>
>>>>>>> 2012/4/23 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'll be happy to contribute, after I have fixed my issues getting
>>>>>>>> avr-llvm to compile in the first place.
>>>>>>>>
>>>>>>>> BR,
>>>>>>>> Nicklas
>>>>>>>>
>>>>>>>> On Sun, Apr 22, 2012 at 7:26 PM, Borja Ferrer <
>>>>>>>> bor...@gm...> wrote:
>>>>>>>>
>>>>>>>>> I think it's time to stop adding more features until we cover what
>>>>>>>>> is currently implemented with regression tests. Otherwise the further we go
>>>>>>>>> the harder will be to cover everything up, from now on it's going to be
>>>>>>>>> easier to go in parallel.
>>>>>>>>> In the past emails I've seen people interested in helping out with
>>>>>>>>> this, it's a good way of starting with some development becuase it's an
>>>>>>>>> easy task to do and it helps to understand how llvm works, so anybody
>>>>>>>>> interested check in here so I know if I'm going to have any help at all or
>>>>>>>>> I have to do it myself.
>>>>>>>>>
>>>>>>>>> So if there's some help available we can plan in this thread what
>>>>>>>>> needs to get covered and how to do it, I'll wait a few days for any replies.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> For Developers, A Lot Can Happen In A Second.
>>>>>>>>> Boundary is the first to Know...and Tell You.
>>>>>>>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>>>>>>>>> http://p.sf.net/sfu/Boundary-d2dvs2
>>>>>>>>> _______________________________________________
>>>>>>>>> avr-llvm-devel mailing list
>>>>>>>>> avr...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Live Security Virtual Conference
>>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>>> threat landscape has changed and how IT managers can respond.
>>>>>>> Discussions
>>>>>>> will include endpoint security, mobile security and the latest in
>>>>>>> malware
>>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> avr-llvm-devel mailing list
>>>>>>> avr...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [avr-llvm-devel] Regression tests

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

> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...]
> Sent: Monday, April 30, 2012 12:22 PM
> To: Nicklas Bo Jensen; John Myers
> Cc: avr...@li...
> Subject: Re: [avr-llvm-devel] Regression tests
> 
> I see what's going here, our version is doing a 16bit addition and then
> truncating it back to 8bits. Are you using clang or dragonegg for the
> frontend? And can you post the llvm asm?
> Also, no need to test imm+imm, only reg+imm and reg+reg will do, the other
> will be constant folded.
> 
> Ah, you'll need svn commit access, John or Eric could you do it?

What's your username?

Eric

Re: [avr-llvm-devel] Regression tests

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

I see what's going here, our version is doing a 16bit addition and then
truncating it back to 8bits. Are you using clang or dragonegg for the
frontend? And can you post the llvm asm?
Also, no need to test imm+imm, only reg+imm and reg+reg will do, the other
will be constant folded.

Ah, you'll need svn commit access, John or Eric could you do it?

2012/4/30 Nicklas Bo Jensen <nbj...@gm...>

> On Mon, Apr 30, 2012 at 12:33 AM, Borja Ferrer <bor...@gm...>
>  wrote:
>
>> It should be similar to what other backends do, in this case we should
>> test adding with 2 regs and then with immediates values, and repeat this
>> for each value type (i8, i16, i32 and i64). Checking the instruction itself
>> is enough, no need to check for registers aswell, that will come in other
>> tests. But when testing with imm values we should check that the imm value
>> is correctly generated, so in this case ignore the reg, but check that the
>> imm field is valid.
>>
>
> Ok, makes sense. I will work on creating the tests.
>
>
>> And what do you mean in that you get different code between gcc and llvm?
>
>
> Basically if I compile:
>
> unsigned char add()
> {
>   unsigned char a,b;
>   a = 5;
>   b = 7;
>   return a+b;
> }
>
>
> with avr-gcc part of the resulting assembler is:
> ldi r24,lo8(5)
>  std Y+1,r24
> ldi r24,lo8(7)
> std Y+2,r24
> ldd r25,Y+1
>  ldd r24,Y+2
> add r24,r25
>
> with clang+avr-llvm part of the resulting assembler is:
>  ldi r24, 5
> std Y+2, r24
> ldi r24, 7
>  std Y+1, r24
> ldd r24, Y+2
>  adiw r25:r24, 7
> andi r24, 255
> andi r25, 0
>
> So they use different approaches(add and adiw) to solve the same problem.
>
> Thanks
> Nicklas
>
> 2012/4/29 Nicklas Bo Jensen <nbj...@gm...>
>>
>>> Sure. Just wanted to actually compile the code before writing tests.
>>>
>>> Got how the test framework works and added a very small test that is
>>> working perfectly.
>>>
>>> How detailed should the test be? Should it check the generated assembly
>>> fully or just the main parts, e.g. the addition itself? For an addition the
>>> avr-llvm version is quite different from the avr-gcc version.
>>>
>>> Thanks,
>>> Nicklas
>>>
>>>
>>>
>>> On Sun, Apr 29, 2012 at 8:07 PM, Borja Ferrer <bor...@gm...>wrote:
>>>
>>>> The problem here is that I've represented register pairs as r29:r28
>>>> while the assembler only wants the low register of the pair, that's why
>>>> you're getting that error but you're doing it right.
>>>>
>>>> But the way of writing regression tests in llvm is different to what
>>>> you're doing. Those tests in SVN are going away once we start writing the
>>>> new ones.
>>>>
>>>> Read this: http://llvm.org/docs/TestingGuide.html
>>>> and then go to
>>>> http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/ and
>>>> choose any target you wish (say msp430 since it's the most similar one to
>>>> us) to see how real tests look like.
>>>>
>>>> Basically, you have to write a test in llvm assembly, and then with
>>>> CHECK you write the avr assembly that should be emitted, if it matches then
>>>> the test passes otherwise it fails. You can avoid writing the llvm assembly
>>>> by writing the test in C and then translate it to llvm assembly with clang.
>>>>
>>>> Try writing a small test for add using the llvm testing infrastructure
>>>> and then run it with llvm to see if it passes.
>>>> It's very important that you write the expected output assembly right,
>>>> otherwise we'll generate wrong code to make the test pass, but since tests
>>>> are quite small it's easy to get it right.
>>>>
>>>>
>>>> 2012/4/29 Nicklas Bo Jensen <nbj...@gm...>
>>>>
>>>>> Hi,
>>>>>
>>>>> I have successfully been able to compile your testcases
>>>>> (/avr-llvm/testcases/*.ll) to something looking like valid avr assembler.
>>>>>
>>>>> How should I test/simulate the assembler? I get errors when trying to
>>>>> simulate the generated assembler in AVRStudio. Perhaps they use a different
>>>>> assembler?
>>>>>
>>>>> For one test, add1.ll I cannot process it using avr-as. I have done:
>>>>>
>>>>> ../../build/Debug+Asserts/bin/llc --march=avr add1.ll -o add1.s
>>>>> avr-as -mmcu=atmega168 add1.s
>>>>>
>>>>>
>>>>> and get the error:
>>>>>
>>>>> asm.s: Assembler messages:
>>>>> asm.s:12: Error: register r24, r26, r28 or r30 required
>>>>> asm.s:12: Error: `,' required
>>>>> asm.s:12: Error: garbage at end of line
>>>>> asm.s:24: Error: register r24, r26, r28 or r30 required
>>>>> asm.s:24: Error: `,' required
>>>>> asm.s:24: Error: garbage at end of line
>>>>>
>>>>>
>>>>> Am I doing something wrong? I have included the assembler.
>>>>>
>>>>> Thanks,
>>>>> Nicklas
>>>>>
>>>>> On Sun, Apr 29, 2012 at 7:23 PM, Borja Ferrer <bor...@gm...>wrote:
>>>>>
>>>>>> Hello Neil I'm replying you in this thread, i dont know why I didn't
>>>>>> receive your mail, i had to look in SF to read it.
>>>>>>
>>>>>> Anyways, first try to build the backend so you can play a bit with it
>>>>>> to get familiar with its code. Try compiling some C code to generate avr
>>>>>> assembly.
>>>>>>
>>>>>> 2012/4/23 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'll be happy to contribute, after I have fixed my issues getting
>>>>>>> avr-llvm to compile in the first place.
>>>>>>>
>>>>>>> BR,
>>>>>>> Nicklas
>>>>>>>
>>>>>>> On Sun, Apr 22, 2012 at 7:26 PM, Borja Ferrer <bor...@gm...
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> I think it's time to stop adding more features until we cover what
>>>>>>>> is currently implemented with regression tests. Otherwise the further we go
>>>>>>>> the harder will be to cover everything up, from now on it's going to be
>>>>>>>> easier to go in parallel.
>>>>>>>> In the past emails I've seen people interested in helping out with
>>>>>>>> this, it's a good way of starting with some development becuase it's an
>>>>>>>> easy task to do and it helps to understand how llvm works, so anybody
>>>>>>>> interested check in here so I know if I'm going to have any help at all or
>>>>>>>> I have to do it myself.
>>>>>>>>
>>>>>>>> So if there's some help available we can plan in this thread what
>>>>>>>> needs to get covered and how to do it, I'll wait a few days for any replies.
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> For Developers, A Lot Can Happen In A Second.
>>>>>>>> Boundary is the first to Know...and Tell You.
>>>>>>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>>>>>>>> http://p.sf.net/sfu/Boundary-d2dvs2
>>>>>>>> _______________________________________________
>>>>>>>> avr-llvm-devel mailing list
>>>>>>>> avr...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Live Security Virtual Conference
>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>> threat landscape has changed and how IT managers can respond.
>>>>>> Discussions
>>>>>> will include endpoint security, mobile security and the latest in
>>>>>> malware
>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>>
>>>>>> _______________________________________________
>>>>>> avr-llvm-devel mailing list
>>>>>> avr...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [avr-llvm-devel] Regression tests

[Nicklas Bo J. <nbj...@gm...>]

On Mon, Apr 30, 2012 at 12:33 AM, Borja Ferrer <bor...@gm...>
 wrote:

> It should be similar to what other backends do, in this case we should
> test adding with 2 regs and then with immediates values, and repeat this
> for each value type (i8, i16, i32 and i64). Checking the instruction itself
> is enough, no need to check for registers aswell, that will come in other
> tests. But when testing with imm values we should check that the imm value
> is correctly generated, so in this case ignore the reg, but check that the
> imm field is valid.
>

Ok, makes sense. I will work on creating the tests.


> And what do you mean in that you get different code between gcc and llvm?


Basically if I compile:

unsigned char add()
{
  unsigned char a,b;
  a = 5;
  b = 7;
  return a+b;
}


with avr-gcc part of the resulting assembler is:
ldi r24,lo8(5)
std Y+1,r24
ldi r24,lo8(7)
std Y+2,r24
ldd r25,Y+1
ldd r24,Y+2
add r24,r25

with clang+avr-llvm part of the resulting assembler is:
ldi r24, 5
std Y+2, r24
ldi r24, 7
std Y+1, r24
ldd r24, Y+2
adiw r25:r24, 7
andi r24, 255
andi r25, 0

So they use different approaches(add and adiw) to solve the same problem.

Thanks
Nicklas

2012/4/29 Nicklas Bo Jensen <nbj...@gm...>
>
>> Sure. Just wanted to actually compile the code before writing tests.
>>
>> Got how the test framework works and added a very small test that is
>> working perfectly.
>>
>> How detailed should the test be? Should it check the generated assembly
>> fully or just the main parts, e.g. the addition itself? For an addition the
>> avr-llvm version is quite different from the avr-gcc version.
>>
>> Thanks,
>> Nicklas
>>
>>
>>
>> On Sun, Apr 29, 2012 at 8:07 PM, Borja Ferrer <bor...@gm...>wrote:
>>
>>> The problem here is that I've represented register pairs as r29:r28
>>> while the assembler only wants the low register of the pair, that's why
>>> you're getting that error but you're doing it right.
>>>
>>> But the way of writing regression tests in llvm is different to what
>>> you're doing. Those tests in SVN are going away once we start writing the
>>> new ones.
>>>
>>> Read this: http://llvm.org/docs/TestingGuide.html
>>> and then go to
>>> http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/ and choose
>>> any target you wish (say msp430 since it's the most similar one to us) to
>>> see how real tests look like.
>>>
>>> Basically, you have to write a test in llvm assembly, and then with
>>> CHECK you write the avr assembly that should be emitted, if it matches then
>>> the test passes otherwise it fails. You can avoid writing the llvm assembly
>>> by writing the test in C and then translate it to llvm assembly with clang.
>>>
>>> Try writing a small test for add using the llvm testing infrastructure
>>> and then run it with llvm to see if it passes.
>>> It's very important that you write the expected output assembly right,
>>> otherwise we'll generate wrong code to make the test pass, but since tests
>>> are quite small it's easy to get it right.
>>>
>>>
>>> 2012/4/29 Nicklas Bo Jensen <nbj...@gm...>
>>>
>>>> Hi,
>>>>
>>>> I have successfully been able to compile your testcases
>>>> (/avr-llvm/testcases/*.ll) to something looking like valid avr assembler.
>>>>
>>>> How should I test/simulate the assembler? I get errors when trying to
>>>> simulate the generated assembler in AVRStudio. Perhaps they use a different
>>>> assembler?
>>>>
>>>> For one test, add1.ll I cannot process it using avr-as. I have done:
>>>>
>>>> ../../build/Debug+Asserts/bin/llc --march=avr add1.ll -o add1.s
>>>> avr-as -mmcu=atmega168 add1.s
>>>>
>>>>
>>>> and get the error:
>>>>
>>>> asm.s: Assembler messages:
>>>> asm.s:12: Error: register r24, r26, r28 or r30 required
>>>> asm.s:12: Error: `,' required
>>>> asm.s:12: Error: garbage at end of line
>>>> asm.s:24: Error: register r24, r26, r28 or r30 required
>>>> asm.s:24: Error: `,' required
>>>> asm.s:24: Error: garbage at end of line
>>>>
>>>>
>>>> Am I doing something wrong? I have included the assembler.
>>>>
>>>> Thanks,
>>>> Nicklas
>>>>
>>>> On Sun, Apr 29, 2012 at 7:23 PM, Borja Ferrer <bor...@gm...>wrote:
>>>>
>>>>> Hello Neil I'm replying you in this thread, i dont know why I didn't
>>>>> receive your mail, i had to look in SF to read it.
>>>>>
>>>>> Anyways, first try to build the backend so you can play a bit with it
>>>>> to get familiar with its code. Try compiling some C code to generate avr
>>>>> assembly.
>>>>>
>>>>> 2012/4/23 Nicklas Bo Jensen <nbj...@gm...>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'll be happy to contribute, after I have fixed my issues getting
>>>>>> avr-llvm to compile in the first place.
>>>>>>
>>>>>> BR,
>>>>>> Nicklas
>>>>>>
>>>>>> On Sun, Apr 22, 2012 at 7:26 PM, Borja Ferrer <bor...@gm...>wrote:
>>>>>>
>>>>>>> I think it's time to stop adding more features until we cover what
>>>>>>> is currently implemented with regression tests. Otherwise the further we go
>>>>>>> the harder will be to cover everything up, from now on it's going to be
>>>>>>> easier to go in parallel.
>>>>>>> In the past emails I've seen people interested in helping out with
>>>>>>> this, it's a good way of starting with some development becuase it's an
>>>>>>> easy task to do and it helps to understand how llvm works, so anybody
>>>>>>> interested check in here so I know if I'm going to have any help at all or
>>>>>>> I have to do it myself.
>>>>>>>
>>>>>>> So if there's some help available we can plan in this thread what
>>>>>>> needs to get covered and how to do it, I'll wait a few days for any replies.
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> For Developers, A Lot Can Happen In A Second.
>>>>>>> Boundary is the first to Know...and Tell You.
>>>>>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>>>>>>> http://p.sf.net/sfu/Boundary-d2dvs2
>>>>>>> _______________________________________________
>>>>>>> avr-llvm-devel mailing list
>>>>>>> avr...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Live Security Virtual Conference
>>>>> Exclusive live event will cover all the ways today's security and
>>>>> threat landscape has changed and how IT managers can respond.
>>>>> Discussions
>>>>> will include endpoint security, mobile security and the latest in
>>>>> malware
>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>
>>>>> _______________________________________________
>>>>> avr-llvm-devel mailing list
>>>>> avr...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [avr-llvm-devel] Regression tests

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

It should be similar to what other backends do, in this case we should test
adding with 2 regs and then with immediates values, and repeat this for
each value type (i8, i16, i32 and i64). Checking the instruction itself is
enough, no need to check for registers aswell, that will come in other
tests. But when testing with imm values we should check that the imm value
is correctly generated, so in this case ignore the reg, but check that the
imm field is valid.

And what do you mean in that you get different code between gcc and llvm?

2012/4/29 Nicklas Bo Jensen <nbj...@gm...>

> Sure. Just wanted to actually compile the code before writing tests.
>
> Got how the test framework works and added a very small test that is
> working perfectly.
>
> How detailed should the test be? Should it check the generated assembly
> fully or just the main parts, e.g. the addition itself? For an addition the
> avr-llvm version is quite different from the avr-gcc version.
>
> Thanks,
> Nicklas
>
>
>
> On Sun, Apr 29, 2012 at 8:07 PM, Borja Ferrer <bor...@gm...>wrote:
>
>> The problem here is that I've represented register pairs as r29:r28 while
>> the assembler only wants the low register of the pair, that's why you're
>> getting that error but you're doing it right.
>>
>> But the way of writing regression tests in llvm is different to what
>> you're doing. Those tests in SVN are going away once we start writing the
>> new ones.
>>
>> Read this: http://llvm.org/docs/TestingGuide.html
>> and then go to
>> http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/ and choose
>> any target you wish (say msp430 since it's the most similar one to us) to
>> see how real tests look like.
>>
>> Basically, you have to write a test in llvm assembly, and then with CHECK
>> you write the avr assembly that should be emitted, if it matches then the
>> test passes otherwise it fails. You can avoid writing the llvm assembly by
>> writing the test in C and then translate it to llvm assembly with clang.
>>
>> Try writing a small test for add using the llvm testing infrastructure
>> and then run it with llvm to see if it passes.
>> It's very important that you write the expected output assembly right,
>> otherwise we'll generate wrong code to make the test pass, but since tests
>> are quite small it's easy to get it right.
>>
>>
>> 2012/4/29 Nicklas Bo Jensen <nbj...@gm...>
>>
>>> Hi,
>>>
>>> I have successfully been able to compile your testcases
>>> (/avr-llvm/testcases/*.ll) to something looking like valid avr assembler.
>>>
>>> How should I test/simulate the assembler? I get errors when trying to
>>> simulate the generated assembler in AVRStudio. Perhaps they use a different
>>> assembler?
>>>
>>> For one test, add1.ll I cannot process it using avr-as. I have done:
>>>
>>> ../../build/Debug+Asserts/bin/llc --march=avr add1.ll -o add1.s
>>> avr-as -mmcu=atmega168 add1.s
>>>
>>>
>>> and get the error:
>>>
>>> asm.s: Assembler messages:
>>> asm.s:12: Error: register r24, r26, r28 or r30 required
>>> asm.s:12: Error: `,' required
>>> asm.s:12: Error: garbage at end of line
>>> asm.s:24: Error: register r24, r26, r28 or r30 required
>>> asm.s:24: Error: `,' required
>>> asm.s:24: Error: garbage at end of line
>>>
>>>
>>> Am I doing something wrong? I have included the assembler.
>>>
>>> Thanks,
>>> Nicklas
>>>
>>> On Sun, Apr 29, 2012 at 7:23 PM, Borja Ferrer <bor...@gm...>wrote:
>>>
>>>> Hello Neil I'm replying you in this thread, i dont know why I didn't
>>>> receive your mail, i had to look in SF to read it.
>>>>
>>>> Anyways, first try to build the backend so you can play a bit with it
>>>> to get familiar with its code. Try compiling some C code to generate avr
>>>> assembly.
>>>>
>>>> 2012/4/23 Nicklas Bo Jensen <nbj...@gm...>
>>>>
>>>>> Hi,
>>>>>
>>>>> I'll be happy to contribute, after I have fixed my issues getting
>>>>> avr-llvm to compile in the first place.
>>>>>
>>>>> BR,
>>>>> Nicklas
>>>>>
>>>>> On Sun, Apr 22, 2012 at 7:26 PM, Borja Ferrer <bor...@gm...>wrote:
>>>>>
>>>>>> I think it's time to stop adding more features until we cover what is
>>>>>> currently implemented with regression tests. Otherwise the further we go
>>>>>> the harder will be to cover everything up, from now on it's going to be
>>>>>> easier to go in parallel.
>>>>>> In the past emails I've seen people interested in helping out with
>>>>>> this, it's a good way of starting with some development becuase it's an
>>>>>> easy task to do and it helps to understand how llvm works, so anybody
>>>>>> interested check in here so I know if I'm going to have any help at all or
>>>>>> I have to do it myself.
>>>>>>
>>>>>> So if there's some help available we can plan in this thread what
>>>>>> needs to get covered and how to do it, I'll wait a few days for any replies.
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> For Developers, A Lot Can Happen In A Second.
>>>>>> Boundary is the first to Know...and Tell You.
>>>>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>>>>>> http://p.sf.net/sfu/Boundary-d2dvs2
>>>>>> _______________________________________________
>>>>>> avr-llvm-devel mailing list
>>>>>> avr...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond.
>>>> Discussions
>>>> will include endpoint security, mobile security and the latest in
>>>> malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>
>>>> _______________________________________________
>>>> avr-llvm-devel mailing list
>>>> avr...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>>>
>>>>
>>>
>>
>

Re: [avr-llvm-devel] Regression tests

[Nicklas Bo J. <nbj...@gm...>]

Sure. Just wanted to actually compile the code before writing tests.

Got how the test framework works and added a very small test that is
working perfectly.

How detailed should the test be? Should it check the generated assembly
fully or just the main parts, e.g. the addition itself? For an addition the
avr-llvm version is quite different from the avr-gcc version.

Thanks,
Nicklas



On Sun, Apr 29, 2012 at 8:07 PM, Borja Ferrer <bor...@gm...> wrote:

> The problem here is that I've represented register pairs as r29:r28 while
> the assembler only wants the low register of the pair, that's why you're
> getting that error but you're doing it right.
>
> But the way of writing regression tests in llvm is different to what
> you're doing. Those tests in SVN are going away once we start writing the
> new ones.
>
> Read this: http://llvm.org/docs/TestingGuide.html
> and then go to
> http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/ and choose
> any target you wish (say msp430 since it's the most similar one to us) to
> see how real tests look like.
>
> Basically, you have to write a test in llvm assembly, and then with CHECK
> you write the avr assembly that should be emitted, if it matches then the
> test passes otherwise it fails. You can avoid writing the llvm assembly by
> writing the test in C and then translate it to llvm assembly with clang.
>
> Try writing a small test for add using the llvm testing infrastructure and
> then run it with llvm to see if it passes.
> It's very important that you write the expected output assembly right,
> otherwise we'll generate wrong code to make the test pass, but since tests
> are quite small it's easy to get it right.
>
>
> 2012/4/29 Nicklas Bo Jensen <nbj...@gm...>
>
>> Hi,
>>
>> I have successfully been able to compile your testcases
>> (/avr-llvm/testcases/*.ll) to something looking like valid avr assembler.
>>
>> How should I test/simulate the assembler? I get errors when trying to
>> simulate the generated assembler in AVRStudio. Perhaps they use a different
>> assembler?
>>
>> For one test, add1.ll I cannot process it using avr-as. I have done:
>>
>> ../../build/Debug+Asserts/bin/llc --march=avr add1.ll -o add1.s
>> avr-as -mmcu=atmega168 add1.s
>>
>>
>> and get the error:
>>
>> asm.s: Assembler messages:
>> asm.s:12: Error: register r24, r26, r28 or r30 required
>> asm.s:12: Error: `,' required
>> asm.s:12: Error: garbage at end of line
>> asm.s:24: Error: register r24, r26, r28 or r30 required
>> asm.s:24: Error: `,' required
>> asm.s:24: Error: garbage at end of line
>>
>>
>> Am I doing something wrong? I have included the assembler.
>>
>> Thanks,
>> Nicklas
>>
>> On Sun, Apr 29, 2012 at 7:23 PM, Borja Ferrer <bor...@gm...>wrote:
>>
>>> Hello Neil I'm replying you in this thread, i dont know why I didn't
>>> receive your mail, i had to look in SF to read it.
>>>
>>> Anyways, first try to build the backend so you can play a bit with it to
>>> get familiar with its code. Try compiling some C code to generate avr
>>> assembly.
>>>
>>> 2012/4/23 Nicklas Bo Jensen <nbj...@gm...>
>>>
>>>> Hi,
>>>>
>>>> I'll be happy to contribute, after I have fixed my issues getting
>>>> avr-llvm to compile in the first place.
>>>>
>>>> BR,
>>>> Nicklas
>>>>
>>>> On Sun, Apr 22, 2012 at 7:26 PM, Borja Ferrer <bor...@gm...>wrote:
>>>>
>>>>> I think it's time to stop adding more features until we cover what is
>>>>> currently implemented with regression tests. Otherwise the further we go
>>>>> the harder will be to cover everything up, from now on it's going to be
>>>>> easier to go in parallel.
>>>>> In the past emails I've seen people interested in helping out with
>>>>> this, it's a good way of starting with some development becuase it's an
>>>>> easy task to do and it helps to understand how llvm works, so anybody
>>>>> interested check in here so I know if I'm going to have any help at all or
>>>>> I have to do it myself.
>>>>>
>>>>> So if there's some help available we can plan in this thread what
>>>>> needs to get covered and how to do it, I'll wait a few days for any replies.
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> For Developers, A Lot Can Happen In A Second.
>>>>> Boundary is the first to Know...and Tell You.
>>>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>>>>> http://p.sf.net/sfu/Boundary-d2dvs2
>>>>> _______________________________________________
>>>>> avr-llvm-devel mailing list
>>>>> avr...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>>>>
>>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>
>>> _______________________________________________
>>> avr-llvm-devel mailing list
>>> avr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>>
>>>
>>
>

Re: [avr-llvm-devel] Flash data

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

John I've seen you've updated some patches, but remember to fix the code
you removed from a patch file.

2012/4/22 Borja Ferrer <bor...@gm...>

> Ok, thanks John.
>
>
> 2012/4/20 John Myers <ato...@gm...>
>
>> I haven't had time to fix it.
>> I'll probably be able to do it this weekend.
>>
>>
>> On Fri, Apr 20, 2012 at 8:02 AM, Borja Ferrer <bor...@gm...>wrote:
>>
>>> John ping?
>>>
>>>
>>> 2012/4/12 Borja Ferrer <bor...@gm...>
>>>
>>>> John I noticed that in your latest commit you removed a piece of valid
>>>> code inside lib/CodeGen/TargetInfo.cpp, although this code is for flash
>>>> variables, it goes under the code that handles interrupt attributes.
>>>>
>>>>   +  } else
>>>>  +    // Global variables that do not belong to the generic address
>>>> space and
>>>>  +    // have common linkage are set to have external linkage.
>>>>  +    if ((GV->getType()->getAddressSpace() != 0)
>>>>  +        && (GV->getLinkage() == llvm::GlobalValue::CommonLinkage))
>>>>  +      GV->setLinkage(llvm::GlobalValue::ExternalLinkage);
>>>>  +}
>>>> You may want to place this bit in the interrupt patch or something, I
>>>> leave that up to you.
>>>>
>>>> Btw has anybody tried or tested the backend lately? I would like to
>>>> hear some opinions.
>>>>
>>>>
>>>> 2012/3/20 Borja Ferrer <bor...@gm...>
>>>>
>>>>> Ok I've just commited all patches and code related to this. Please try
>>>>> them out and let me know any issues. John you'll notice some patches
>>>>> duplicate some code compared to the interrupt.diff file because i added
>>>>> some code to the same files like that patch, you may want to fix this, I
>>>>> didnt know what to do.
>>>>>
>>>>>
>>>>> 2012/3/19 Borja Ferrer <bor...@gm...>
>>>>>
>>>>>> Indeed __flash is a type qualifier just like const or volatile, the
>>>>>> syntax you're all writing above is how it works. You can have an insane
>>>>>> chain of pointers like __flash const int * const __flash * * const __flash
>>>>>> * __flash ptr; and it's totally valid. The issue I'm talking about is,
>>>>>> should __flash qualify a variable with a const aswell? As we discussed
>>>>>> above i think it shouldn't.
>>>>>>
>>>>>> Anton, what you said in the last email is exactly what I think, as
>>>>>> __flash is a type qualifier, check for constness and add errors if the user
>>>>>> doesn't explicitly add them. But after all the usage is what you're all
>>>>>> writing above. I like the idea of adding const because it really models how
>>>>>> flash memory works, and as i said making __flash imply const is like
>>>>>> cheating on the C language. But well, we're all here to discuss about it so
>>>>>> it's not a closed decision in any sense.
>>>>>>
>>>>>> John thanks for the strings, I'll add them to my patch. If you want,
>>>>>> once it is commited you can add further changes or add any additional
>>>>>> hints. I still have to prepare the patch because I was waiting for this, I
>>>>>> will split it in 2 parts, one for the clang side and another for llvm.
>>>>>>
>>>>>> Oh and if anybody else can think of any additional checks let me
>>>>>> know, we should be here as robust as possible.
>>>>>>
>>>>>>
>>>>>> 2012/3/19 John Myers <ato...@gm...>
>>>>>>
>>>>>>>
>>>>>>> 1) Cannot write to flash memory. <-- emitted when trying to assign a
>>>>>>>> value to a flash var
>>>>>>>>
>>>>>>> The error for a const being assigned a value is "error: read-only
>>>>>>> variable is not assignable" so I would make the wording consistent and just
>>>>>>> do...
>>>>>>>
>>>>>>>       "error: Flash variable is not assignable"       ...or...
>>>>>>>       "error: __flash qualified variable is not assignable"
>>>>>>>
>>>>>>>
>>>>>>>> 2) Flash variables are read only and should be declared with a
>>>>>>>> const qualifier. <-- emitted when doing something like __flash int, we want
>>>>>>>> __flash const int
>>>>>>>>
>>>>>>>
>>>>>>> Something like the below and then also have one of those clang
>>>>>>> fix-it hints showing const being added.
>>>>>>>
>>>>>>>    "error: Flash variable requires const qualifier"
>>>>>>>
>>>>>>> 3) The pointee type of a flash pointer should be declared with a
>>>>>>>> const qualifier. <-- i cant think of a better way of saying it, this is
>>>>>>>> emitted when doing __flash int* ptr, we want __flash const int *ptr.
>>>>>>>>
>>>>>>>
>>>>>>> I think this can be the same as or similar to #2 and again use the
>>>>>>> fix-it hint to show explicitly where the const needs to be placed.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [avr-llvm-devel] Regression tests

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

The problem here is that I've represented register pairs as r29:r28 while
the assembler only wants the low register of the pair, that's why you're
getting that error but you're doing it right.

But the way of writing regression tests in llvm is different to what you're
doing. Those tests in SVN are going away once we start writing the new ones.

Read this: http://llvm.org/docs/TestingGuide.html
and then go to http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/and
choose any target you wish (say msp430 since it's the most similar one
to us) to see how real tests look like.

Basically, you have to write a test in llvm assembly, and then with CHECK
you write the avr assembly that should be emitted, if it matches then the
test passes otherwise it fails. You can avoid writing the llvm assembly by
writing the test in C and then translate it to llvm assembly with clang.

Try writing a small test for add using the llvm testing infrastructure and
then run it with llvm to see if it passes.
It's very important that you write the expected output assembly right,
otherwise we'll generate wrong code to make the test pass, but since tests
are quite small it's easy to get it right.

2012/4/29 Nicklas Bo Jensen <nbj...@gm...>

> Hi,
>
> I have successfully been able to compile your testcases
> (/avr-llvm/testcases/*.ll) to something looking like valid avr assembler.
>
> How should I test/simulate the assembler? I get errors when trying to
> simulate the generated assembler in AVRStudio. Perhaps they use a different
> assembler?
>
> For one test, add1.ll I cannot process it using avr-as. I have done:
>
> ../../build/Debug+Asserts/bin/llc --march=avr add1.ll -o add1.s
> avr-as -mmcu=atmega168 add1.s
>
>
> and get the error:
>
> asm.s: Assembler messages:
> asm.s:12: Error: register r24, r26, r28 or r30 required
> asm.s:12: Error: `,' required
> asm.s:12: Error: garbage at end of line
> asm.s:24: Error: register r24, r26, r28 or r30 required
> asm.s:24: Error: `,' required
> asm.s:24: Error: garbage at end of line
>
>
> Am I doing something wrong? I have included the assembler.
>
> Thanks,
> Nicklas
>
> On Sun, Apr 29, 2012 at 7:23 PM, Borja Ferrer <bor...@gm...>wrote:
>
>> Hello Neil I'm replying you in this thread, i dont know why I didn't
>> receive your mail, i had to look in SF to read it.
>>
>> Anyways, first try to build the backend so you can play a bit with it to
>> get familiar with its code. Try compiling some C code to generate avr
>> assembly.
>>
>> 2012/4/23 Nicklas Bo Jensen <nbj...@gm...>
>>
>>> Hi,
>>>
>>> I'll be happy to contribute, after I have fixed my issues getting
>>> avr-llvm to compile in the first place.
>>>
>>> BR,
>>> Nicklas
>>>
>>> On Sun, Apr 22, 2012 at 7:26 PM, Borja Ferrer <bor...@gm...>wrote:
>>>
>>>> I think it's time to stop adding more features until we cover what is
>>>> currently implemented with regression tests. Otherwise the further we go
>>>> the harder will be to cover everything up, from now on it's going to be
>>>> easier to go in parallel.
>>>> In the past emails I've seen people interested in helping out with
>>>> this, it's a good way of starting with some development becuase it's an
>>>> easy task to do and it helps to understand how llvm works, so anybody
>>>> interested check in here so I know if I'm going to have any help at all or
>>>> I have to do it myself.
>>>>
>>>> So if there's some help available we can plan in this thread what needs
>>>> to get covered and how to do it, I'll wait a few days for any replies.
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> For Developers, A Lot Can Happen In A Second.
>>>> Boundary is the first to Know...and Tell You.
>>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>>>> http://p.sf.net/sfu/Boundary-d2dvs2
>>>> _______________________________________________
>>>> avr-llvm-devel mailing list
>>>> avr...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>>>
>>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>
>> _______________________________________________
>> avr-llvm-devel mailing list
>> avr...@li...
>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>
>>
>

Re: [avr-llvm-devel] Regression tests

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

Hello Neil I'm replying you in this thread, i dont know why I didn't
receive your mail, i had to look in SF to read it.

Anyways, first try to build the backend so you can play a bit with it to
get familiar with its code. Try compiling some C code to generate avr
assembly.

2012/4/23 Nicklas Bo Jensen <nbj...@gm...>

> Hi,
>
> I'll be happy to contribute, after I have fixed my issues getting avr-llvm
> to compile in the first place.
>
> BR,
> Nicklas
>
> On Sun, Apr 22, 2012 at 7:26 PM, Borja Ferrer <bor...@gm...>wrote:
>
>> I think it's time to stop adding more features until we cover what is
>> currently implemented with regression tests. Otherwise the further we go
>> the harder will be to cover everything up, from now on it's going to be
>> easier to go in parallel.
>> In the past emails I've seen people interested in helping out with this,
>> it's a good way of starting with some development becuase it's an easy task
>> to do and it helps to understand how llvm works, so anybody interested
>> check in here so I know if I'm going to have any help at all or I have to
>> do it myself.
>>
>> So if there's some help available we can plan in this thread what needs
>> to get covered and how to do it, I'll wait a few days for any replies.
>>
>>
>> ------------------------------------------------------------------------------
>> For Developers, A Lot Can Happen In A Second.
>> Boundary is the first to Know...and Tell You.
>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2
>> _______________________________________________
>> avr-llvm-devel mailing list
>> avr...@li...
>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>
>>
>

Re: [avr-llvm-devel] Fwd: Problem following Getting started with avr-llvm

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

Ahh so then it's something common to other backends, we can check these
failures later on in case we need to fix something.

You should be able to compile anything that doesn't use varargs or inline
asm (maybe something more i cant remember now), if something is failing it
needs to be fixed, that's why i want to get regression tests now, to catch
all failures before adding more features.

Please repost this email in the regression test thread so we can discuss it
there, then i'll reply you in that thread.

2012/4/29 Nicklas Bo Jensen <nbj...@gm...>

> Hi,
>
> Hi,
>
> First of all I got the exact same test results when building for another
> target(msp430 and clean svn checkout of llvm).
>
> I'm not really sure how far you guys are with the backend, but I have
> successfully been able to compile your testcases (/avr-llvm/testcases/*.ll)
> to something looking like valid avr assembler.
>
> I'm a bit confused about:
>
>    - Which device(mmcu) does the generated assembler target?
>    - How should I test/simulate the assembler? I get errors when trying
>    to simulate the generated assembler in AVRStudio and cannot process it
>    using avr-as(e.g. avr-as -mmcu=atmega168 add1.s).
>
>
> Thanks,
> Nicklas
>
> On Tue, Apr 24, 2012 at 2:26 AM, Borja Ferrer <bor...@gm...>wrote:
>
>> Great!
>>
>> I have no idea about the tests yet, I've never run the test suite before.
>> If they fail with other targets then it's normal, otherwise it'll need to
>> be addressed.
>> I'll let you some time to play with the backend before really doing some
>> work, if you have any doubts ask them here.
>>
>>
>> 2012/4/24 Nicklas Bo Jensen <nbj...@gm...>
>>
>>> Manually patching llvm/configure and llvm/projects/sample/configure did
>>> the trick. Thanks!
>>>
>>> Are many of the checks supposed to fail when performing make check?
>>> (Unexpected Failures: 225)
>>>
>>> llc seems to be working allright now :)
>>>
>>> On Mon, Apr 23, 2012 at 11:53 PM, Borja Ferrer <bor...@gm...>wrote:
>>>
>>>> Ahh ok I didn't receive the message from John, so i thought he never
>>>> replied to you.
>>>>
>>>> No, there's no special revision needed from llvm's repo, it should
>>>> always compile with the latest svn revision, I keep our code in sync with
>>>> llvm's trunk when any API change occurs, like during the past weekend.
>>>>
>>>> Remember to add --enable-targets=avr when configuring the build,
>>>> probably one of your files got corrupted after patching, try using a fresh
>>>> configure (or CMakelists.txt if you're using windows) file and build llvm
>>>> without the avr target. If that works then there's the problem, I would
>>>> then patch the configure file manually, just search the word msp430 and add
>>>> avr the same way it's done. Check other patch files that touch the building
>>>> stuff like CMake.diff<http://avr-llvm.svn.sourceforge.net/viewvc/avr-llvm/llvm/trunk/patches/CMake.diff?view=log>and
>>>> LLVMBuild.diff<http://avr-llvm.svn.sourceforge.net/viewvc/avr-llvm/llvm/trunk/patches/LLVMBuild.diff?view=log>.
>>>> I think the problem is related with one of those, not patches that touch
>>>> the sourcecode.
>>>>
>>>>
>>>> 2012/4/23 Nicklas Bo Jensen <nbj...@gm...>
>>>>
>>>>> Hi,
>>>>>
>>>>> He did reply to my message:
>>>>> On Wed, Apr 11, 2012 at 7:30 PM, John Myers <ato...@gm...>
>>>>>  wrote:
>>>>>
>>>>>> Hi Nicklas,
>>>>>>
>>>>>> Sorry, The getting started page needs to be updated. I've always just
>>>>>> applied the patch files one at a time, so I never checked to see if this
>>>>>> method works. But I get the same error when trying to apply the patches
>>>>>> with ../avr-llvm/patches/*.diff | patch -p0
>>>>>>
>>>>>> You can try something like the below instead.
>>>>>> echo ../avr-llvm/llvm/trunk/patches/*.diff > patch -p0
>>>>>>
>>>>>>
>>>>>> --John
>>>>>
>>>>>
>>>>> I ended up applying the patches one by one though, as patch returned
>>>>>  "**** Only garbage was found in the patch input." when using echo and
>>>>> "malformed patch at line 16: Index: CMakeLists.txt" when using cat.
>>>>>
>>>>> Should any special revision of llvm be checked out? Right now the
>>>>> latest revision in the patches is 152169.
>>>>>
>>>>> I'm getting the following configure error (Regardless of chosen llvm
>>>>> revision):
>>>>>
>>>>> config.status: error: cannot find input file: tools/llvmc/src/
>>>>> Base.td.in
>>>>>
>>>>> Indeed the file is not there?
>>>>>
>>>>> I have followed the instructions in: avr-llvm/README and can normally
>>>>> compile llvm+clang directly from svn.
>>>>>
>>>>> BR,
>>>>> Nicklas
>>>>>
>>>>> On Fri, Apr 20, 2012 at 5:06 PM, Borja Ferrer <bor...@gm...>wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Please wait for John to reply here about issues with patches since
>>>>>> he's the one that usually work with them.
>>>>>>
>>>>>> CCing John.
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> For Developers, A Lot Can Happen In A Second.
>>>>>> Boundary is the first to Know...and Tell You.
>>>>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>>>>>> http://p.sf.net/sfu/Boundary-d2dvs2
>>>>>> _______________________________________________
>>>>>> avr-llvm-devel mailing list
>>>>>> avr...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [avr-llvm-devel] Regression tests

[Neil F. <inf...@gm...>]

I'm up for helping with tests, so count me in.
I'm a newbie at this, and haven't gotten the AVR target building yet.
But I've got the code and have successfully applied the patches a few
times, so I think I can get myself working and up to speed.
-Neil


On Mon, Apr 23, 2012 at 6:01 PM,
<avr...@li...> wrote:
> Send avr-llvm-devel mailing list submissions to
>        avr...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
> or, via email, send a message with subject or body 'help' to
>        avr...@li...
>
> You can reach the person managing the list at
>        avr...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of avr-llvm-devel digest..."
>
>
> Today's Topics:
>
>   1. Regression tests (Borja Ferrer)
>   2. Re: Flash data (Borja Ferrer)
>   3. Re: Regression tests (Nicklas Bo Jensen)
>   4. Re: Fwd: Problem following Getting started with   avr-llvm
>      (Borja Ferrer)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 22 Apr 2012 19:26:05 +0200
> From: Borja Ferrer <bor...@gm...>
> Subject: [avr-llvm-devel] Regression tests
> To: avr...@li...
> Message-ID:
>        <CAM...@ma...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I think it's time to stop adding more features until we cover what is
> currently implemented with regression tests. Otherwise the further we go
> the harder will be to cover everything up, from now on it's going to be
> easier to go in parallel.
> In the past emails I've seen people interested in helping out with this,
> it's a good way of starting with some development becuase it's an easy task
> to do and it helps to understand how llvm works, so anybody interested
> check in here so I know if I'm going to have any help at all or I have to
> do it myself.
>
> So if there's some help available we can plan in this thread what needs to
> get covered and how to do it, I'll wait a few days for any replies.
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 2
> Date: Sun, 22 Apr 2012 19:26:38 +0200
> From: Borja Ferrer <bor...@gm...>
> Subject: Re: [avr-llvm-devel] Flash data
> To: John Myers <ato...@gm...>
> Cc: avr...@li...
> Message-ID:
>        <CAM...@ma...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Ok, thanks John.
>
> 2012/4/20 John Myers <ato...@gm...>
>
>> I haven't had time to fix it.
>> I'll probably be able to do it this weekend.
>>
>>
>> On Fri, Apr 20, 2012 at 8:02 AM, Borja Ferrer <bor...@gm...>wrote:
>>
>>> John ping?
>>>
>>>
>>> 2012/4/12 Borja Ferrer <bor...@gm...>
>>>
>>>> John I noticed that in your latest commit you removed a piece of valid
>>>> code inside lib/CodeGen/TargetInfo.cpp, although this code is for flash
>>>> variables, it goes under the code that handles interrupt attributes.
>>>>
>>>>   +  } else
>>>>  +    // Global variables that do not belong to the generic address
>>>> space and
>>>>  +    // have common linkage are set to have external linkage.
>>>>  +    if ((GV->getType()->getAddressSpace() != 0)
>>>>  +        && (GV->getLinkage() == llvm::GlobalValue::CommonLinkage))
>>>>  +      GV->setLinkage(llvm::GlobalValue::ExternalLinkage);
>>>>  +}
>>>> You may want to place this bit in the interrupt patch or something, I
>>>> leave that up to you.
>>>>
>>>> Btw has anybody tried or tested the backend lately? I would like to hear
>>>> some opinions.
>>>>
>>>>
>>>> 2012/3/20 Borja Ferrer <bor...@gm...>
>>>>
>>>>> Ok I've just commited all patches and code related to this. Please try
>>>>> them out and let me know any issues. John you'll notice some patches
>>>>> duplicate some code compared to the interrupt.diff file because i added
>>>>> some code to the same files like that patch, you may want to fix this, I
>>>>> didnt know what to do.
>>>>>
>>>>>
>>>>> 2012/3/19 Borja Ferrer <bor...@gm...>
>>>>>
>>>>>> Indeed __flash is a type qualifier just like const or volatile, the
>>>>>> syntax you're all writing above is how it works. You can have an insane
>>>>>> chain of pointers like __flash const int * const __flash * * const __flash
>>>>>> * __flash ptr; and it's totally valid. The issue I'm talking about is,
>>>>>> should __flash qualify a variable with a const aswell? As we discussed
>>>>>> above i think it shouldn't.
>>>>>>
>>>>>> Anton, what you said in the last email is exactly what I think, as
>>>>>> __flash is a type qualifier, check for constness and add errors if the user
>>>>>> doesn't explicitly add them. But after all the usage is what you're all
>>>>>> writing above. I like the idea of adding const because it really models how
>>>>>> flash memory works, and as i said making __flash imply const is like
>>>>>> cheating on the C language. But well, we're all here to discuss about it so
>>>>>> it's not a closed decision in any sense.
>>>>>>
>>>>>> John thanks for the strings, I'll add them to my patch. If you want,
>>>>>> once it is commited you can add further changes or add any additional
>>>>>> hints. I still have to prepare the patch because I was waiting for this, I
>>>>>> will split it in 2 parts, one for the clang side and another for llvm.
>>>>>>
>>>>>> Oh and if anybody else can think of any additional checks let me know,
>>>>>> we should be here as robust as possible.
>>>>>>
>>>>>>
>>>>>> 2012/3/19 John Myers <ato...@gm...>
>>>>>>
>>>>>>>
>>>>>>> 1) Cannot write to flash memory. <-- emitted when trying to assign a
>>>>>>>> value to a flash var
>>>>>>>>
>>>>>>> The error for a const being assigned a value is "error: read-only
>>>>>>> variable is not assignable" so I would make the wording consistent and just
>>>>>>> do...
>>>>>>>
>>>>>>>       "error: Flash variable is not assignable"       ...or...
>>>>>>>       "error: __flash qualified variable is not assignable"
>>>>>>>
>>>>>>>
>>>>>>>> 2) Flash variables are read only and should be declared with a const
>>>>>>>> qualifier. <-- emitted when doing something like __flash int, we want
>>>>>>>> __flash const int
>>>>>>>>
>>>>>>>
>>>>>>> Something like the below and then also have one of those clang fix-it
>>>>>>> hints showing const being added.
>>>>>>>
>>>>>>>    "error: Flash variable requires const qualifier"
>>>>>>>
>>>>>>> 3) The pointee type of a flash pointer should be declared with a
>>>>>>>> const qualifier. <-- i cant think of a better way of saying it, this is
>>>>>>>> emitted when doing __flash int* ptr, we want __flash const int *ptr.
>>>>>>>>
>>>>>>>
>>>>>>> I think this can be the same as or similar to #2 and again use the
>>>>>>> fix-it hint to show explicitly where the const needs to be placed.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 3
> Date: Mon, 23 Apr 2012 22:26:53 +0200
> From: Nicklas Bo Jensen <nbj...@gm...>
> Subject: Re: [avr-llvm-devel] Regression tests
> To: Borja Ferrer <bor...@gm...>
> Cc: avr...@li...
> Message-ID:
>        <CAM...@ma...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> I'll be happy to contribute, after I have fixed my issues getting avr-llvm
> to compile in the first place.
>
> BR,
> Nicklas
>
> On Sun, Apr 22, 2012 at 7:26 PM, Borja Ferrer <bor...@gm...> wrote:
>
>> I think it's time to stop adding more features until we cover what is
>> currently implemented with regression tests. Otherwise the further we go
>> the harder will be to cover everything up, from now on it's going to be
>> easier to go in parallel.
>> In the past emails I've seen people interested in helping out with this,
>> it's a good way of starting with some development becuase it's an easy task
>> to do and it helps to understand how llvm works, so anybody interested
>> check in here so I know if I'm going to have any help at all or I have to
>> do it myself.
>>
>> So if there's some help available we can plan in this thread what needs to
>> get covered and how to do it, I'll wait a few days for any replies.
>>
>>
>> ------------------------------------------------------------------------------
>> For Developers, A Lot Can Happen In A Second.
>> Boundary is the first to Know...and Tell You.
>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2
>> _______________________________________________
>> avr-llvm-devel mailing list
>> avr...@li...
>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 4
> Date: Mon, 23 Apr 2012 23:53:40 +0200
> From: Borja Ferrer <bor...@gm...>
> Subject: Re: [avr-llvm-devel] Fwd: Problem following Getting started
>        with    avr-llvm
> To: Nicklas Bo Jensen <nbj...@gm...>
> Cc: avr...@li...
> Message-ID:
>        <CAMOECusZfLsNupRC+wHvwSk8xuHt-Rfx=0iq...@ma...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Ahh ok I didn't receive the message from John, so i thought he never
> replied to you.
>
> No, there's no special revision needed from llvm's repo, it should always
> compile with the latest svn revision, I keep our code in sync with llvm's
> trunk when any API change occurs, like during the past weekend.
>
> Remember to add --enable-targets=avr when configuring the build, probably
> one of your files got corrupted after patching, try using a fresh configure
> (or CMakelists.txt if you're using windows) file and build llvm without the
> avr target. If that works then there's the problem, I would then patch the
> configure file manually, just search the word msp430 and add avr the same
> way it's done. Check other patch files that touch the building stuff like
> CMake.diff<http://avr-llvm.svn.sourceforge.net/viewvc/avr-llvm/llvm/trunk/patches/CMake.diff?view=log>and
> LLVMBuild.diff<http://avr-llvm.svn.sourceforge.net/viewvc/avr-llvm/llvm/trunk/patches/LLVMBuild.diff?view=log>.
> I think the problem is related with one of those, not patches that touch
> the sourcecode.
>
> 2012/4/23 Nicklas Bo Jensen <nbj...@gm...>
>
>> Hi,
>>
>> He did reply to my message:
>> On Wed, Apr 11, 2012 at 7:30 PM, John Myers <ato...@gm...>
>>  wrote:
>>
>>> Hi Nicklas,
>>>
>>> Sorry, The getting started page needs to be updated. I've always just
>>> applied the patch files one at a time, so I never checked to see if this
>>> method works. But I get the same error when trying to apply the patches
>>> with ../avr-llvm/patches/*.diff | patch -p0
>>>
>>> You can try something like the below instead.
>>> echo ../avr-llvm/llvm/trunk/patches/*.diff > patch -p0
>>>
>>>
>>> --John
>>
>>
>> I ended up applying the patches one by one though, as patch returned
>>  "**** Only garbage was found in the patch input." when using echo and
>> "malformed patch at line 16: Index: CMakeLists.txt" when using cat.
>>
>> Should any special revision of llvm be checked out? Right now the latest
>> revision in the patches is 152169.
>>
>> I'm getting the following configure error (Regardless of chosen llvm
>> revision):
>>
>> config.status: error: cannot find input file: tools/llvmc/src/Base.td.in
>>
>> Indeed the file is not there?
>>
>> I have followed the instructions in: avr-llvm/README and can normally
>> compile llvm+clang directly from svn.
>>
>> BR,
>> Nicklas
>>
>> On Fri, Apr 20, 2012 at 5:06 PM, Borja Ferrer <bor...@gm...>wrote:
>>
>>> Hello,
>>>
>>> Please wait for John to reply here about issues with patches since he's
>>> the one that usually work with them.
>>>
>>> CCing John.
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> For Developers, A Lot Can Happen In A Second.
>>> Boundary is the first to Know...and Tell You.
>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>>> http://p.sf.net/sfu/Boundary-d2dvs2
>>> _______________________________________________
>>> avr-llvm-devel mailing list
>>> avr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>>
>>>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
>
>
> ------------------------------
>
> _______________________________________________
> avr-llvm-devel mailing list
> avr...@li...
> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>
>
> End of avr-llvm-devel Digest, Vol 16, Issue 3
> *********************************************

Re: [avr-llvm-devel] Problem following Getting started with avr-llvm

[David A. L. <dl...@ly...>]

On Apr 23, 2012, at 1:24 PM, Nicklas Bo Jensen wrote:

> He did reply to my message:
> On Wed, Apr 11, 2012 at 7:30 PM, John Myers <ato...@gm...> wrote:
> Hi Nicklas,
> 
> Sorry, The getting started page needs to be updated. I've always just applied the patch files one at a time, so I never checked to see if this method works. But I get the same error when trying to apply the patches with ../avr-llvm/patches/*.diff | patch -p0
> 
> You can try something like the below instead.
> echo ../avr-llvm/llvm/trunk/patches/*.diff > patch -p0
> 
> 
> --John

The way I've always used 'patch', that should be 'cat' and '|':

	cat ../avr-llvm/llvm/trunk/patches/*.diff | patch -p0

The "echo ... > patch -p0" may appear to succeed, but all it did was echo the pathnames of the patch files, and the text "-p0", into a new file in the current directory, called "patch".
The 'cat', on the other hand, outputs the contents of the files, and the '|' provides that content to the 'patch' command.

Cheers,

--Dave

Re: [avr-llvm-devel] Fwd: Problem following Getting started with avr-llvm

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

Great!

I have no idea about the tests yet, I've never run the test suite before.
If they fail with other targets then it's normal, otherwise it'll need to
be addressed.
I'll let you some time to play with the backend before really doing some
work, if you have any doubts ask them here.

2012/4/24 Nicklas Bo Jensen <nbj...@gm...>

> Manually patching llvm/configure and llvm/projects/sample/configure did
> the trick. Thanks!
>
> Are many of the checks supposed to fail when performing make check?
> (Unexpected Failures: 225)
>
> llc seems to be working allright now :)
>
> On Mon, Apr 23, 2012 at 11:53 PM, Borja Ferrer <bor...@gm...>wrote:
>
>> Ahh ok I didn't receive the message from John, so i thought he never
>> replied to you.
>>
>> No, there's no special revision needed from llvm's repo, it should always
>> compile with the latest svn revision, I keep our code in sync with llvm's
>> trunk when any API change occurs, like during the past weekend.
>>
>> Remember to add --enable-targets=avr when configuring the build, probably
>> one of your files got corrupted after patching, try using a fresh configure
>> (or CMakelists.txt if you're using windows) file and build llvm without the
>> avr target. If that works then there's the problem, I would then patch the
>> configure file manually, just search the word msp430 and add avr the same
>> way it's done. Check other patch files that touch the building stuff like
>> CMake.diff<http://avr-llvm.svn.sourceforge.net/viewvc/avr-llvm/llvm/trunk/patches/CMake.diff?view=log>and
>> LLVMBuild.diff<http://avr-llvm.svn.sourceforge.net/viewvc/avr-llvm/llvm/trunk/patches/LLVMBuild.diff?view=log>.
>> I think the problem is related with one of those, not patches that touch
>> the sourcecode.
>>
>>
>> 2012/4/23 Nicklas Bo Jensen <nbj...@gm...>
>>
>>> Hi,
>>>
>>> He did reply to my message:
>>> On Wed, Apr 11, 2012 at 7:30 PM, John Myers <ato...@gm...>
>>>  wrote:
>>>
>>>> Hi Nicklas,
>>>>
>>>> Sorry, The getting started page needs to be updated. I've always just
>>>> applied the patch files one at a time, so I never checked to see if this
>>>> method works. But I get the same error when trying to apply the patches
>>>> with ../avr-llvm/patches/*.diff | patch -p0
>>>>
>>>> You can try something like the below instead.
>>>> echo ../avr-llvm/llvm/trunk/patches/*.diff > patch -p0
>>>>
>>>>
>>>> --John
>>>
>>>
>>> I ended up applying the patches one by one though, as patch returned
>>>  "**** Only garbage was found in the patch input." when using echo and
>>> "malformed patch at line 16: Index: CMakeLists.txt" when using cat.
>>>
>>> Should any special revision of llvm be checked out? Right now the latest
>>> revision in the patches is 152169.
>>>
>>> I'm getting the following configure error (Regardless of chosen llvm
>>> revision):
>>>
>>> config.status: error: cannot find input file: tools/llvmc/src/Base.td.in
>>>
>>> Indeed the file is not there?
>>>
>>> I have followed the instructions in: avr-llvm/README and can normally
>>> compile llvm+clang directly from svn.
>>>
>>> BR,
>>> Nicklas
>>>
>>> On Fri, Apr 20, 2012 at 5:06 PM, Borja Ferrer <bor...@gm...>wrote:
>>>
>>>> Hello,
>>>>
>>>> Please wait for John to reply here about issues with patches since he's
>>>> the one that usually work with them.
>>>>
>>>> CCing John.
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> For Developers, A Lot Can Happen In A Second.
>>>> Boundary is the first to Know...and Tell You.
>>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>>>> http://p.sf.net/sfu/Boundary-d2dvs2
>>>> _______________________________________________
>>>> avr-llvm-devel mailing list
>>>> avr...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>>>
>>>>
>>>
>>
>

Re: [avr-llvm-devel] Fwd: Problem following Getting started with avr-llvm

[Nicklas Bo J. <nbj...@gm...>]

Manually patching llvm/configure and llvm/projects/sample/configure did the
trick. Thanks!

Are many of the checks supposed to fail when performing make check?
(Unexpected Failures: 225)

llc seems to be working allright now :)

On Mon, Apr 23, 2012 at 11:53 PM, Borja Ferrer <bor...@gm...>wrote:

> Ahh ok I didn't receive the message from John, so i thought he never
> replied to you.
>
> No, there's no special revision needed from llvm's repo, it should always
> compile with the latest svn revision, I keep our code in sync with llvm's
> trunk when any API change occurs, like during the past weekend.
>
> Remember to add --enable-targets=avr when configuring the build, probably
> one of your files got corrupted after patching, try using a fresh configure
> (or CMakelists.txt if you're using windows) file and build llvm without the
> avr target. If that works then there's the problem, I would then patch the
> configure file manually, just search the word msp430 and add avr the same
> way it's done. Check other patch files that touch the building stuff like
> CMake.diff<http://avr-llvm.svn.sourceforge.net/viewvc/avr-llvm/llvm/trunk/patches/CMake.diff?view=log>and
> LLVMBuild.diff<http://avr-llvm.svn.sourceforge.net/viewvc/avr-llvm/llvm/trunk/patches/LLVMBuild.diff?view=log>.
> I think the problem is related with one of those, not patches that touch
> the sourcecode.
>
>
> 2012/4/23 Nicklas Bo Jensen <nbj...@gm...>
>
>> Hi,
>>
>> He did reply to my message:
>> On Wed, Apr 11, 2012 at 7:30 PM, John Myers <ato...@gm...>
>>  wrote:
>>
>>> Hi Nicklas,
>>>
>>> Sorry, The getting started page needs to be updated. I've always just
>>> applied the patch files one at a time, so I never checked to see if this
>>> method works. But I get the same error when trying to apply the patches
>>> with ../avr-llvm/patches/*.diff | patch -p0
>>>
>>> You can try something like the below instead.
>>> echo ../avr-llvm/llvm/trunk/patches/*.diff > patch -p0
>>>
>>>
>>> --John
>>
>>
>> I ended up applying the patches one by one though, as patch returned
>>  "**** Only garbage was found in the patch input." when using echo and
>> "malformed patch at line 16: Index: CMakeLists.txt" when using cat.
>>
>> Should any special revision of llvm be checked out? Right now the latest
>> revision in the patches is 152169.
>>
>> I'm getting the following configure error (Regardless of chosen llvm
>> revision):
>>
>> config.status: error: cannot find input file: tools/llvmc/src/Base.td.in
>>
>> Indeed the file is not there?
>>
>> I have followed the instructions in: avr-llvm/README and can normally
>> compile llvm+clang directly from svn.
>>
>> BR,
>> Nicklas
>>
>> On Fri, Apr 20, 2012 at 5:06 PM, Borja Ferrer <bor...@gm...>wrote:
>>
>>> Hello,
>>>
>>> Please wait for John to reply here about issues with patches since he's
>>> the one that usually work with them.
>>>
>>> CCing John.
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> For Developers, A Lot Can Happen In A Second.
>>> Boundary is the first to Know...and Tell You.
>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>>> http://p.sf.net/sfu/Boundary-d2dvs2
>>> _______________________________________________
>>> avr-llvm-devel mailing list
>>> avr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>>
>>>
>>
>

Re: [avr-llvm-devel] Fwd: Problem following Getting started with avr-llvm

[Nicklas Bo J. <nbj...@gm...>]

Hi,

He did reply to my message:
On Wed, Apr 11, 2012 at 7:30 PM, John Myers <ato...@gm...> wrote:

> Hi Nicklas,
>
> Sorry, The getting started page needs to be updated. I've always just
> applied the patch files one at a time, so I never checked to see if this
> method works. But I get the same error when trying to apply the patches
> with ../avr-llvm/patches/*.diff | patch -p0
>
> You can try something like the below instead.
> echo ../avr-llvm/llvm/trunk/patches/*.diff > patch -p0
>
>
> --John


I ended up applying the patches one by one though, as patch returned  "****
Only garbage was found in the patch input." when using echo and "malformed
patch at line 16: Index: CMakeLists.txt" when using cat.

Should any special revision of llvm be checked out? Right now the latest
revision in the patches is 152169.

I'm getting the following configure error (Regardless of chosen llvm
revision):

config.status: error: cannot find input file: tools/llvmc/src/Base.td.in

Indeed the file is not there?

I have followed the instructions in: avr-llvm/README and can normally
compile llvm+clang directly from svn.

BR,
Nicklas

On Fri, Apr 20, 2012 at 5:06 PM, Borja Ferrer <bor...@gm...> wrote:

> Hello,
>
> Please wait for John to reply here about issues with patches since he's
> the one that usually work with them.
>
> CCing John.
>
>
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> avr-llvm-devel mailing list
> avr...@li...
> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>
>

Re: [avr-llvm-devel] Fwd: Problem following Getting started with avr-llvm

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

Ahh ok I didn't receive the message from John, so i thought he never
replied to you.

No, there's no special revision needed from llvm's repo, it should always
compile with the latest svn revision, I keep our code in sync with llvm's
trunk when any API change occurs, like during the past weekend.

Remember to add --enable-targets=avr when configuring the build, probably
one of your files got corrupted after patching, try using a fresh configure
(or CMakelists.txt if you're using windows) file and build llvm without the
avr target. If that works then there's the problem, I would then patch the
configure file manually, just search the word msp430 and add avr the same
way it's done. Check other patch files that touch the building stuff like
CMake.diff<http://avr-llvm.svn.sourceforge.net/viewvc/avr-llvm/llvm/trunk/patches/CMake.diff?view=log>and
LLVMBuild.diff<http://avr-llvm.svn.sourceforge.net/viewvc/avr-llvm/llvm/trunk/patches/LLVMBuild.diff?view=log>.
I think the problem is related with one of those, not patches that touch
the sourcecode.

2012/4/23 Nicklas Bo Jensen <nbj...@gm...>

> Hi,
>
> He did reply to my message:
> On Wed, Apr 11, 2012 at 7:30 PM, John Myers <ato...@gm...>
>  wrote:
>
>> Hi Nicklas,
>>
>> Sorry, The getting started page needs to be updated. I've always just
>> applied the patch files one at a time, so I never checked to see if this
>> method works. But I get the same error when trying to apply the patches
>> with ../avr-llvm/patches/*.diff | patch -p0
>>
>> You can try something like the below instead.
>> echo ../avr-llvm/llvm/trunk/patches/*.diff > patch -p0
>>
>>
>> --John
>
>
> I ended up applying the patches one by one though, as patch returned
>  "**** Only garbage was found in the patch input." when using echo and
> "malformed patch at line 16: Index: CMakeLists.txt" when using cat.
>
> Should any special revision of llvm be checked out? Right now the latest
> revision in the patches is 152169.
>
> I'm getting the following configure error (Regardless of chosen llvm
> revision):
>
> config.status: error: cannot find input file: tools/llvmc/src/Base.td.in
>
> Indeed the file is not there?
>
> I have followed the instructions in: avr-llvm/README and can normally
> compile llvm+clang directly from svn.
>
> BR,
> Nicklas
>
> On Fri, Apr 20, 2012 at 5:06 PM, Borja Ferrer <bor...@gm...>wrote:
>
>> Hello,
>>
>> Please wait for John to reply here about issues with patches since he's
>> the one that usually work with them.
>>
>> CCing John.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> For Developers, A Lot Can Happen In A Second.
>> Boundary is the first to Know...and Tell You.
>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2
>> _______________________________________________
>> avr-llvm-devel mailing list
>> avr...@li...
>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>
>>
>

Re: [avr-llvm-devel] Regression tests

[Nicklas Bo J. <nbj...@gm...>]

Hi,

I'll be happy to contribute, after I have fixed my issues getting avr-llvm
to compile in the first place.

BR,
Nicklas

On Sun, Apr 22, 2012 at 7:26 PM, Borja Ferrer <bor...@gm...> wrote:

> I think it's time to stop adding more features until we cover what is
> currently implemented with regression tests. Otherwise the further we go
> the harder will be to cover everything up, from now on it's going to be
> easier to go in parallel.
> In the past emails I've seen people interested in helping out with this,
> it's a good way of starting with some development becuase it's an easy task
> to do and it helps to understand how llvm works, so anybody interested
> check in here so I know if I'm going to have any help at all or I have to
> do it myself.
>
> So if there's some help available we can plan in this thread what needs to
> get covered and how to do it, I'll wait a few days for any replies.
>
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> avr-llvm-devel mailing list
> avr...@li...
> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>
>

Re: [avr-llvm-devel] Flash data

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

Ok, thanks John.

2012/4/20 John Myers <ato...@gm...>

> I haven't had time to fix it.
> I'll probably be able to do it this weekend.
>
>
> On Fri, Apr 20, 2012 at 8:02 AM, Borja Ferrer <bor...@gm...>wrote:
>
>> John ping?
>>
>>
>> 2012/4/12 Borja Ferrer <bor...@gm...>
>>
>>> John I noticed that in your latest commit you removed a piece of valid
>>> code inside lib/CodeGen/TargetInfo.cpp, although this code is for flash
>>> variables, it goes under the code that handles interrupt attributes.
>>>
>>>   +  } else
>>>  +    // Global variables that do not belong to the generic address
>>> space and
>>>  +    // have common linkage are set to have external linkage.
>>>  +    if ((GV->getType()->getAddressSpace() != 0)
>>>  +        && (GV->getLinkage() == llvm::GlobalValue::CommonLinkage))
>>>  +      GV->setLinkage(llvm::GlobalValue::ExternalLinkage);
>>>  +}
>>> You may want to place this bit in the interrupt patch or something, I
>>> leave that up to you.
>>>
>>> Btw has anybody tried or tested the backend lately? I would like to hear
>>> some opinions.
>>>
>>>
>>> 2012/3/20 Borja Ferrer <bor...@gm...>
>>>
>>>> Ok I've just commited all patches and code related to this. Please try
>>>> them out and let me know any issues. John you'll notice some patches
>>>> duplicate some code compared to the interrupt.diff file because i added
>>>> some code to the same files like that patch, you may want to fix this, I
>>>> didnt know what to do.
>>>>
>>>>
>>>> 2012/3/19 Borja Ferrer <bor...@gm...>
>>>>
>>>>> Indeed __flash is a type qualifier just like const or volatile, the
>>>>> syntax you're all writing above is how it works. You can have an insane
>>>>> chain of pointers like __flash const int * const __flash * * const __flash
>>>>> * __flash ptr; and it's totally valid. The issue I'm talking about is,
>>>>> should __flash qualify a variable with a const aswell? As we discussed
>>>>> above i think it shouldn't.
>>>>>
>>>>> Anton, what you said in the last email is exactly what I think, as
>>>>> __flash is a type qualifier, check for constness and add errors if the user
>>>>> doesn't explicitly add them. But after all the usage is what you're all
>>>>> writing above. I like the idea of adding const because it really models how
>>>>> flash memory works, and as i said making __flash imply const is like
>>>>> cheating on the C language. But well, we're all here to discuss about it so
>>>>> it's not a closed decision in any sense.
>>>>>
>>>>> John thanks for the strings, I'll add them to my patch. If you want,
>>>>> once it is commited you can add further changes or add any additional
>>>>> hints. I still have to prepare the patch because I was waiting for this, I
>>>>> will split it in 2 parts, one for the clang side and another for llvm.
>>>>>
>>>>> Oh and if anybody else can think of any additional checks let me know,
>>>>> we should be here as robust as possible.
>>>>>
>>>>>
>>>>> 2012/3/19 John Myers <ato...@gm...>
>>>>>
>>>>>>
>>>>>> 1) Cannot write to flash memory. <-- emitted when trying to assign a
>>>>>>> value to a flash var
>>>>>>>
>>>>>> The error for a const being assigned a value is "error: read-only
>>>>>> variable is not assignable" so I would make the wording consistent and just
>>>>>> do...
>>>>>>
>>>>>>       "error: Flash variable is not assignable"       ...or...
>>>>>>       "error: __flash qualified variable is not assignable"
>>>>>>
>>>>>>
>>>>>>> 2) Flash variables are read only and should be declared with a const
>>>>>>> qualifier. <-- emitted when doing something like __flash int, we want
>>>>>>> __flash const int
>>>>>>>
>>>>>>
>>>>>> Something like the below and then also have one of those clang fix-it
>>>>>> hints showing const being added.
>>>>>>
>>>>>>    "error: Flash variable requires const qualifier"
>>>>>>
>>>>>> 3) The pointee type of a flash pointer should be declared with a
>>>>>>> const qualifier. <-- i cant think of a better way of saying it, this is
>>>>>>> emitted when doing __flash int* ptr, we want __flash const int *ptr.
>>>>>>>
>>>>>>
>>>>>> I think this can be the same as or similar to #2 and again use the
>>>>>> fix-it hint to show explicitly where the const needs to be placed.
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

[avr-llvm-devel] Regression tests

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

I think it's time to stop adding more features until we cover what is
currently implemented with regression tests. Otherwise the further we go
the harder will be to cover everything up, from now on it's going to be
easier to go in parallel.
In the past emails I've seen people interested in helping out with this,
it's a good way of starting with some development becuase it's an easy task
to do and it helps to understand how llvm works, so anybody interested
check in here so I know if I'm going to have any help at all or I have to
do it myself.

So if there's some help available we can plan in this thread what needs to
get covered and how to do it, I'll wait a few days for any replies.

Re: [avr-llvm-devel] Flash data

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

I haven't had time to fix it.
I'll probably be able to do it this weekend.

On Fri, Apr 20, 2012 at 8:02 AM, Borja Ferrer <bor...@gm...> wrote:

> John ping?
>
>
> 2012/4/12 Borja Ferrer <bor...@gm...>
>
>> John I noticed that in your latest commit you removed a piece of valid
>> code inside lib/CodeGen/TargetInfo.cpp, although this code is for flash
>> variables, it goes under the code that handles interrupt attributes.
>>
>>   +  } else
>>  +    // Global variables that do not belong to the generic address space
>> and
>>  +    // have common linkage are set to have external linkage.
>>  +    if ((GV->getType()->getAddressSpace() != 0)
>>  +        && (GV->getLinkage() == llvm::GlobalValue::CommonLinkage))
>>  +      GV->setLinkage(llvm::GlobalValue::ExternalLinkage);
>>  +}
>> You may want to place this bit in the interrupt patch or something, I
>> leave that up to you.
>>
>> Btw has anybody tried or tested the backend lately? I would like to hear
>> some opinions.
>>
>>
>> 2012/3/20 Borja Ferrer <bor...@gm...>
>>
>>> Ok I've just commited all patches and code related to this. Please try
>>> them out and let me know any issues. John you'll notice some patches
>>> duplicate some code compared to the interrupt.diff file because i added
>>> some code to the same files like that patch, you may want to fix this, I
>>> didnt know what to do.
>>>
>>>
>>> 2012/3/19 Borja Ferrer <bor...@gm...>
>>>
>>>> Indeed __flash is a type qualifier just like const or volatile, the
>>>> syntax you're all writing above is how it works. You can have an insane
>>>> chain of pointers like __flash const int * const __flash * * const __flash
>>>> * __flash ptr; and it's totally valid. The issue I'm talking about is,
>>>> should __flash qualify a variable with a const aswell? As we discussed
>>>> above i think it shouldn't.
>>>>
>>>> Anton, what you said in the last email is exactly what I think, as
>>>> __flash is a type qualifier, check for constness and add errors if the user
>>>> doesn't explicitly add them. But after all the usage is what you're all
>>>> writing above. I like the idea of adding const because it really models how
>>>> flash memory works, and as i said making __flash imply const is like
>>>> cheating on the C language. But well, we're all here to discuss about it so
>>>> it's not a closed decision in any sense.
>>>>
>>>> John thanks for the strings, I'll add them to my patch. If you want,
>>>> once it is commited you can add further changes or add any additional
>>>> hints. I still have to prepare the patch because I was waiting for this, I
>>>> will split it in 2 parts, one for the clang side and another for llvm.
>>>>
>>>> Oh and if anybody else can think of any additional checks let me know,
>>>> we should be here as robust as possible.
>>>>
>>>>
>>>> 2012/3/19 John Myers <ato...@gm...>
>>>>
>>>>>
>>>>> 1) Cannot write to flash memory. <-- emitted when trying to assign a
>>>>>> value to a flash var
>>>>>>
>>>>> The error for a const being assigned a value is "error: read-only
>>>>> variable is not assignable" so I would make the wording consistent and just
>>>>> do...
>>>>>
>>>>>       "error: Flash variable is not assignable"       ...or...
>>>>>       "error: __flash qualified variable is not assignable"
>>>>>
>>>>>
>>>>>> 2) Flash variables are read only and should be declared with a const
>>>>>> qualifier. <-- emitted when doing something like __flash int, we want
>>>>>> __flash const int
>>>>>>
>>>>>
>>>>> Something like the below and then also have one of those clang fix-it
>>>>> hints showing const being added.
>>>>>
>>>>>    "error: Flash variable requires const qualifier"
>>>>>
>>>>> 3) The pointee type of a flash pointer should be declared with a const
>>>>>> qualifier. <-- i cant think of a better way of saying it, this is emitted
>>>>>> when doing __flash int* ptr, we want __flash const int *ptr.
>>>>>>
>>>>>
>>>>> I think this can be the same as or similar to #2 and again use the
>>>>> fix-it hint to show explicitly where the const needs to be placed.
>>>>>
>>>>
>>>>
>>>
>>
>

[avr-llvm-devel] Fwd: Problem following Getting started with avr-llvm

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

Hello,

Please wait for John to reply here about issues with patches since he's the
one that usually work with them.

CCing John.

Re: [avr-llvm-devel] Flash data

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

John ping?

2012/4/12 Borja Ferrer <bor...@gm...>

> John I noticed that in your latest commit you removed a piece of valid
> code inside lib/CodeGen/TargetInfo.cpp, although this code is for flash
> variables, it goes under the code that handles interrupt attributes.
>
>   +  } else
>  +    // Global variables that do not belong to the generic address space
> and
>  +    // have common linkage are set to have external linkage.
>  +    if ((GV->getType()->getAddressSpace() != 0)
>  +        && (GV->getLinkage() == llvm::GlobalValue::CommonLinkage))
>  +      GV->setLinkage(llvm::GlobalValue::ExternalLinkage);
>  +}
> You may want to place this bit in the interrupt patch or something, I
> leave that up to you.
>
> Btw has anybody tried or tested the backend lately? I would like to hear
> some opinions.
>
>
> 2012/3/20 Borja Ferrer <bor...@gm...>
>
>> Ok I've just commited all patches and code related to this. Please try
>> them out and let me know any issues. John you'll notice some patches
>> duplicate some code compared to the interrupt.diff file because i added
>> some code to the same files like that patch, you may want to fix this, I
>> didnt know what to do.
>>
>>
>> 2012/3/19 Borja Ferrer <bor...@gm...>
>>
>>> Indeed __flash is a type qualifier just like const or volatile, the
>>> syntax you're all writing above is how it works. You can have an insane
>>> chain of pointers like __flash const int * const __flash * * const __flash
>>> * __flash ptr; and it's totally valid. The issue I'm talking about is,
>>> should __flash qualify a variable with a const aswell? As we discussed
>>> above i think it shouldn't.
>>>
>>> Anton, what you said in the last email is exactly what I think, as
>>> __flash is a type qualifier, check for constness and add errors if the user
>>> doesn't explicitly add them. But after all the usage is what you're all
>>> writing above. I like the idea of adding const because it really models how
>>> flash memory works, and as i said making __flash imply const is like
>>> cheating on the C language. But well, we're all here to discuss about it so
>>> it's not a closed decision in any sense.
>>>
>>> John thanks for the strings, I'll add them to my patch. If you want,
>>> once it is commited you can add further changes or add any additional
>>> hints. I still have to prepare the patch because I was waiting for this, I
>>> will split it in 2 parts, one for the clang side and another for llvm.
>>>
>>> Oh and if anybody else can think of any additional checks let me know,
>>> we should be here as robust as possible.
>>>
>>>
>>> 2012/3/19 John Myers <ato...@gm...>
>>>
>>>>
>>>> 1) Cannot write to flash memory. <-- emitted when trying to assign a
>>>>> value to a flash var
>>>>>
>>>> The error for a const being assigned a value is "error: read-only
>>>> variable is not assignable" so I would make the wording consistent and just
>>>> do...
>>>>
>>>>       "error: Flash variable is not assignable"       ...or...
>>>>       "error: __flash qualified variable is not assignable"
>>>>
>>>>
>>>>> 2) Flash variables are read only and should be declared with a const
>>>>> qualifier. <-- emitted when doing something like __flash int, we want
>>>>> __flash const int
>>>>>
>>>>
>>>> Something like the below and then also have one of those clang fix-it
>>>> hints showing const being added.
>>>>
>>>>    "error: Flash variable requires const qualifier"
>>>>
>>>> 3) The pointee type of a flash pointer should be declared with a const
>>>>> qualifier. <-- i cant think of a better way of saying it, this is emitted
>>>>> when doing __flash int* ptr, we want __flash const int *ptr.
>>>>>
>>>>
>>>> I think this can be the same as or similar to #2 and again use the
>>>> fix-it hint to show explicitly where the const needs to be placed.
>>>>
>>>
>>>
>>
>

Re: [avr-llvm-devel] Flash data

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

John I noticed that in your latest commit you removed a piece of valid code
inside lib/CodeGen/TargetInfo.cpp, although this code is for flash
variables, it goes under the code that handles interrupt attributes.

 +  } else
 +    // Global variables that do not belong to the generic address space
and
 +    // have common linkage are set to have external linkage.
 +    if ((GV->getType()->getAddressSpace() != 0)
 +        && (GV->getLinkage() == llvm::GlobalValue::CommonLinkage))
 +      GV->setLinkage(llvm::GlobalValue::ExternalLinkage);
 +}
You may want to place this bit in the interrupt patch or something, I leave
that up to you.

Btw has anybody tried or tested the backend lately? I would like to hear
some opinions.

2012/3/20 Borja Ferrer <bor...@gm...>

> Ok I've just commited all patches and code related to this. Please try
> them out and let me know any issues. John you'll notice some patches
> duplicate some code compared to the interrupt.diff file because i added
> some code to the same files like that patch, you may want to fix this, I
> didnt know what to do.
>
>
> 2012/3/19 Borja Ferrer <bor...@gm...>
>
>> Indeed __flash is a type qualifier just like const or volatile, the
>> syntax you're all writing above is how it works. You can have an insane
>> chain of pointers like __flash const int * const __flash * * const __flash
>> * __flash ptr; and it's totally valid. The issue I'm talking about is,
>> should __flash qualify a variable with a const aswell? As we discussed
>> above i think it shouldn't.
>>
>> Anton, what you said in the last email is exactly what I think, as
>> __flash is a type qualifier, check for constness and add errors if the user
>> doesn't explicitly add them. But after all the usage is what you're all
>> writing above. I like the idea of adding const because it really models how
>> flash memory works, and as i said making __flash imply const is like
>> cheating on the C language. But well, we're all here to discuss about it so
>> it's not a closed decision in any sense.
>>
>> John thanks for the strings, I'll add them to my patch. If you want, once
>> it is commited you can add further changes or add any additional hints. I
>> still have to prepare the patch because I was waiting for this, I will
>> split it in 2 parts, one for the clang side and another for llvm.
>>
>> Oh and if anybody else can think of any additional checks let me know, we
>> should be here as robust as possible.
>>
>>
>> 2012/3/19 John Myers <ato...@gm...>
>>
>>>
>>> 1) Cannot write to flash memory. <-- emitted when trying to assign a
>>>> value to a flash var
>>>>
>>> The error for a const being assigned a value is "error: read-only
>>> variable is not assignable" so I would make the wording consistent and just
>>> do...
>>>
>>>       "error: Flash variable is not assignable"       ...or...
>>>       "error: __flash qualified variable is not assignable"
>>>
>>>
>>>> 2) Flash variables are read only and should be declared with a const
>>>> qualifier. <-- emitted when doing something like __flash int, we want
>>>> __flash const int
>>>>
>>>
>>> Something like the below and then also have one of those clang fix-it
>>> hints showing const being added.
>>>
>>>    "error: Flash variable requires const qualifier"
>>>
>>> 3) The pointee type of a flash pointer should be declared with a const
>>>> qualifier. <-- i cant think of a better way of saying it, this is emitted
>>>> when doing __flash int* ptr, we want __flash const int *ptr.
>>>>
>>>
>>> I think this can be the same as or similar to #2 and again use the
>>> fix-it hint to show explicitly where the const needs to be placed.
>>>
>>
>>
>

[avr-llvm-devel] Problem following Getting started with avr-llvm

[Nicklas Bo J. <nbj...@gm...>]

Hi All,

I want to try your really cool project, possibly help out with it, but have
problems getting started. I'm following the instructions in
/avr-llvm/llvm/trunk/docs/gettingstarted.html, are these the current
getting started instructions?

I start by checking out the LLVM source and the avr-llvm source, but are
not able to patch the LLVM source. The command and error is:

../avr-llvm/patches/*.diff | patch -p0
bash: ../avr-llvm/patches/AsmPrinter.diff: Permission denied

What am I doing wrong? All permissions looks fine.

I'm running Linux Mint 12.

BR,
Nicklas