Menu
▾
▴
Re: [avr-llvm-devel] Regression tests
|
From: Borja F. <bor...@gm...> - 2012-05-25 10:41:36
|
Ok I understand it now. Some comments below:
1) The i8 @return8_reg test is fully commented out, can it be removed? I
don't understand what you want to test here.
2) In return64_arg2 the backend will always use Y to read arguments from
the stack, so there's no need to check for Z.
About your calling tests, I can't see them xD
2012/5/25 Nicklas Bo Jensen <nbj...@gm...>
> Is it more clear now? I think those tests have become too complicated and
> we should delete them for now.
>
> Also I'm seeing some wierd code for calling. I've attached a short piece
> of code showing what I think could be a bug. After call foo, we are for
> example doing "adiw r25:r24, 8", but the result from the call is stored
> in these registers. That is not optimal. Also the addition with 5 never
> happens. Is this because the function(calli64_stack) only returns void?
>
> On Fri, May 25, 2012 at 12:06 AM, Nicklas Bo Jensen <nbj...@gm...>wrote:
>
>> Ah i see. I had only implemented correct behaviour in return void, as we
>> had not decided on a test style yet, meaning that those tests for returning
>> the first argument were not testing anything. I have included a new version
>> implementing the check at all cases.
>>
>> The regex is not needed in other tests, where we are not using
>> CHECK-NEXT, as the comments are simply ignored here. When only using CHECK,
>> there can be all kind of things between two CHECK's.
>>
>> On Thu, May 24, 2012 at 11:51 PM, Borja Ferrer <bor...@gm...>wrote:
>>
>>> Yes I understood it xD
>>> What confuses me is that the first CHECK which checks the function name
>>> label has a regex (the return_void: line), while the rest of tests don't
>>> have it, meaning that the comment in the functionname label is not present
>>> OR that when you only check for ret_void: (done in the rest of tests) and
>>> then you use CHECK-NEXT it is still in the same line which doesn't make
>>> sense to me at all, but who knows.
>>>
>>> I see that the BB#0 comment is always printed, so it has to be consumed
>>> before you get into the real instructions.
>>>
>>> Basically if what i wrote is confusing, why is the first regexp needed
>>> and not needed in the rest of cases?
>>>
>>>
>>> 2012/5/24 Nicklas Bo Jensen <nbj...@gm...>
>>>
>>>> Sorry for my bad explanations :)
>>>>
>>>> For returning void and returning the first parameter directly the
>>>> assembly looks like:
>>>> return_void: # @return_void
>>>> # BB#0:
>>>> ret
>>>>
>>>> What I'm thinking is important to test in these cases is that there is
>>>> no code between the label "return_void:" and "ret", only comments.
>>>>
>>>> Here CHECK-NEXT is a good choice, but the two comments makes it much
>>>> harder to use CHECK-NEXT. Therefore the first regexp consumes the comment
>>>> after the label and the second the comment on the next line, if not
>>>> including the first regexp the second will match on the same line as the
>>>> label.
>>>>
>>>> Does that make sense? Essentially it would be much easier to test if
>>>> FileCheck had the option for ignoring comments.
>>>>
>>>>
>>>>
>>>> On Thu, May 24, 2012 at 11:03 PM, Borja Ferrer <bor...@gm...>wrote:
>>>>
>>>>> I'm a bit confused now, why is this comment only appearing in this
>>>>> test then? I mean, for the rest of tests you didn't need to add that regex.
>>>>>
>>>>>
>>>>> 2012/5/24 Nicklas Bo Jensen <nbj...@gm...>
>>>>>
>>>>>> The asm looks something like:
>>>>>> return_void: # @return_void
>>>>>> # BB#0:
>>>>>> ret
>>>>>>
>>>>>> So the two regex's handle one comment each. It's far from perfect,
>>>>>> should we just delete these testcases for now?
>>>>>>
>>>>>> On Thu, May 24, 2012 at 6:40 PM, Borja Ferrer <bor...@gm...>wrote:
>>>>>>
>>>>>>> I prefer the second, although it's a bit nasty it doesn't use an
>>>>>>> external tool. For what is this regex used in CHECK:
>>>>>>> return_void:{{[a-zA-Z0-9 #@]*}} ?
>>>>>>>
>>>>>>>
>>>>>>> 2012/5/24 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>
>>>>>>>> I agree. FileCheck should be able to ignore comments(at least as a
>>>>>>>> parameter) like it ignores whitespaces.
>>>>>>>>
>>>>>>>> However I do have a few suggestions for how to do it, if you like
>>>>>>>> one of them we can use it.
>>>>>>>>
>>>>>>>> 1. Previous suggestion with "hardcoded" comment.
>>>>>>>> 2. Accept any comment after label:
>>>>>>>> define void @return_void() {
>>>>>>>> ; CHECK: return_void:{{[a-zA-Z0-9 #@]*}}
>>>>>>>> ; CHECK-NEXT: #{{[a-zA-Z0-9 #@]*}}
>>>>>>>> ; CHECK-NEXT: ret
>>>>>>>> ret void
>>>>>>>> }
>>>>>>>>
>>>>>>>> 3. Strip the assembler for comments and blank lines(here using sed)
>>>>>>>> before checking.
>>>>>>>> ; RUN: llc < %s -march=avr | sed "s/#.*//" | sed "/^$/d" |
>>>>>>>> FileCheck %s
>>>>>>>>
>>>>>>>> define void @return_void() {
>>>>>>>> ; CHECK: return_void:
>>>>>>>> ; CHECK-NEXT: ret
>>>>>>>> ret void
>>>>>>>> }
>>>>>>>>
>>>>>>>> 2. is a bit complex and if we later choose to not print comments
>>>>>>>> before blocks the test will fail.
>>>>>>>> 3. is simpler, but requires a third party tool.
>>>>>>>>
>>>>>>>> What do you think Borja? I haven't found another backend dealing
>>>>>>>> with this issue.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, May 24, 2012 at 12:33 PM, Borja Ferrer <
>>>>>>>> bor...@gm...> wrote:
>>>>>>>>
>>>>>>>>> I like it but checking for BB#0 is a bit nasty because it's a
>>>>>>>>> comment and not an instruction, also that could change in the future
>>>>>>>>> breaking the test.
>>>>>>>>>
>>>>>>>>> I've checked the other backends and we're testing things further
>>>>>>>>> than what others do so I think there's no need for more tests there.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2012/5/24 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>
>>>>>>>>>> One idea could be to use CHECK-NEXT that checks if the string is
>>>>>>>>>> on a consecutive line, then we could do something like:
>>>>>>>>>>
>>>>>>>>>> define void @return_void() {
>>>>>>>>>> ; CHECK: return_void:
>>>>>>>>>> ; CHECK-NEXT: # BB#0:
>>>>>>>>>> ; CHECK-NEXT: ret
>>>>>>>>>> ret void
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> The solution with the comment is not the best. What do you think?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, May 24, 2012 at 1:48 AM, Borja Ferrer <
>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>
>>>>>>>>>>> Maybe you could check using CHECKNOT or whatever to make sure
>>>>>>>>>>> that no moves are emitted, that would cover it.
>>>>>>>>>>>
>>>>>>>>>>> I'll check what other backends do regarding these tests and see
>>>>>>>>>>> if I can come up with further things.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2012/5/23 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>
>>>>>>>>>>>> Are the following tests obsolete, as there in my opinion is no
>>>>>>>>>>>> really good way to test them using FileCheck(with my current return
>>>>>>>>>>>> tests(included) we could return the wrong argument)?
>>>>>>>>>>>>
>>>>>>>>>>>> - Returning void.
>>>>>>>>>>>> - Returning the first parameter, which is already in the
>>>>>>>>>>>> correct place.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Do we need additional tests for returning, besides
>>>>>>>>>>>> returning immediate and argument, like returning a value from register or
>>>>>>>>>>>> is it already covered in returning a argument?
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, May 23, 2012 at 12:51 AM, Borja Ferrer <
>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, that's something handled by llvm, not the backend so we
>>>>>>>>>>>>> can't do too much there, although it would be a nice optimization to do.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2012/5/23 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for the explanation. It's clear :)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Out of curiosity, why are the pushes and pops in the example
>>>>>>>>>>>>>> below? movw leaves r17:r14 unchanged. Do we simply push and pop all
>>>>>>>>>>>>>> registers to be on the safe side and limited static analysis?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> llvm:
>>>>>>>>>>>>>> define i32 @return32_arg2(i32 %x, i32 %y, i32 %z) {
>>>>>>>>>>>>>> ret i32 %z
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> asm:
>>>>>>>>>>>>>> return32_arg2:
>>>>>>>>>>>>>> push r14
>>>>>>>>>>>>>> push r15
>>>>>>>>>>>>>> push r16
>>>>>>>>>>>>>> push r17
>>>>>>>>>>>>>> movw r23:r22, r15:r14
>>>>>>>>>>>>>> movw r25:r24, r17:r16
>>>>>>>>>>>>>> pop r17
>>>>>>>>>>>>>> pop r16
>>>>>>>>>>>>>> pop r15
>>>>>>>>>>>>>> pop r14
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, May 22, 2012 at 11:32 PM, Borja Ferrer <
>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Here you have a link that explains how registers are used:
>>>>>>>>>>>>>>> www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_reg_usage
>>>>>>>>>>>>>>> Testing a calling convention without knowing how it actually
>>>>>>>>>>>>>>> works is going to be an insane task to do xD
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> About your question, when you read that link all will become
>>>>>>>>>>>>>>> clear but basically here is what's going on. Arguments are passed from r25
>>>>>>>>>>>>>>> down to r8, since in this case three 64bit args can't fit in those
>>>>>>>>>>>>>>> registers the last argument is passed through the stack, so you get:
>>>>>>>>>>>>>>> arg1 is in: r25-r18
>>>>>>>>>>>>>>> arg2 is in: r17-r10
>>>>>>>>>>>>>>> arg3 obviously doesn't fit in 2 register so it's all passed
>>>>>>>>>>>>>>> through the stack, thats why you get those loads. Notice that the lowest
>>>>>>>>>>>>>>> part of the argument is in Y+5 because in +4 and +3 is r29:r28 you just
>>>>>>>>>>>>>>> pushed and in +2 +1 is the the return address that was pushed into the
>>>>>>>>>>>>>>> stack after the call was performed.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Another thing, you should add checks on the pushes and pops
>>>>>>>>>>>>>>> for the callee saved registers so we're sure that they're being saved.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2012/5/22 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Perfect :)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm moving on to calling convention and have started with
>>>>>>>>>>>>>>>> return values. However I'm a bit unsure what the calling convention
>>>>>>>>>>>>>>>> actually is. For example with my last test, called "return64_arg2" in the
>>>>>>>>>>>>>>>> attached .ll file and the generated assembly in the .s file, is the correct
>>>>>>>>>>>>>>>> thing happening and how it should be tested? Couldn't we have passed the
>>>>>>>>>>>>>>>> arguments in the normal registers? I.e. r25:r2.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If the arguments don't fit in the registers, do we always
>>>>>>>>>>>>>>>> store the result in the same place in ram?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Mon, May 21, 2012 at 11:38 PM, Borja Ferrer <
>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Nice, so now you have the same test failures as me, they
>>>>>>>>>>>>>>>>> are caused because we're using custom address space stuff in clang, dont
>>>>>>>>>>>>>>>>> worry about those. Basically they fail because these tests are writing into
>>>>>>>>>>>>>>>>> address space 1 which is flash data and that is forbidden in our target
>>>>>>>>>>>>>>>>> (remember flash memory is readonly).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The test cases you just commited look great :) To which
>>>>>>>>>>>>>>>>> ones are you going to move on next?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yes, that code looks correct, where is the problem?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2012/5/21 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Is the following generated code correct:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> LLVM:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> define i8 @return8_arg(i8 %x) {
>>>>>>>>>>>>>>>>>> ret i8 %x
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Generated:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> return8_arg:
>>>>>>>>>>>>>>>>>> ret
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Something similar in .c compiling with avr-gcc gives a
>>>>>>>>>>>>>>>>>> few pushes, loads and pops.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Mon, May 21, 2012 at 10:48 PM, Nicklas Bo Jensen <
>>>>>>>>>>>>>>>>>> nbj...@gm...> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> When adding those targets I only have 10 unexpected
>>>>>>>>>>>>>>>>>>> failures:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Clang :: CodeGen/address-space-compound-literal.c
>>>>>>>>>>>>>>>>>>> Clang :: CodeGen/address-space-field1.c
>>>>>>>>>>>>>>>>>>> Clang :: CodeGen/address-space.c
>>>>>>>>>>>>>>>>>>> Clang :: CodeGenCXX/mangle-address-space.cpp
>>>>>>>>>>>>>>>>>>> Clang :: PCH/types.c
>>>>>>>>>>>>>>>>>>> Clang :: Sema/address_spaces.c
>>>>>>>>>>>>>>>>>>> Clang :: SemaCXX/address-space-conversion.cpp
>>>>>>>>>>>>>>>>>>> Clang :: SemaCXX/address-space-newdelete.cpp
>>>>>>>>>>>>>>>>>>> Clang :: SemaCXX/address-space-references.cpp
>>>>>>>>>>>>>>>>>>> Clang :: SemaTemplate/address-spaces.cpp
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I will try to run each test separately and try to figure
>>>>>>>>>>>>>>>>>>> out why they are failing. I have also attached the test output.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I'm also committing tests for and, or and xor in a
>>>>>>>>>>>>>>>>>>> minute. They are really simple and similar to the add and sub tests. Please
>>>>>>>>>>>>>>>>>>> review these :)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Mon, May 14, 2012 at 11:32 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Did you try adding the x86 and x64 targets with the avr
>>>>>>>>>>>>>>>>>>>> one? It's something related with an unsopported target.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Good question, I think there's no need to do reg+imm
>>>>>>>>>>>>>>>>>>>> for xor.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Btw remember to add the SF mailing list so we can have
>>>>>>>>>>>>>>>>>>>> a record ;)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2012/5/14 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Sorry, that is the llvm+clang trunk gives me 13
>>>>>>>>>>>>>>>>>>>>> unsupported tests, i.e. no failures versus the avr-llvm giving me 280
>>>>>>>>>>>>>>>>>>>>> unexpected failures.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Mon, May 14, 2012 at 9:08 PM, Nicklas Bo Jensen <
>>>>>>>>>>>>>>>>>>>>> nbj...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> BTW, the newest llvm and clang trunk only gives me 13
>>>>>>>>>>>>>>>>>>>>>> unexpected failures compared to the the newest trunk with avr-llvm where i
>>>>>>>>>>>>>>>>>>>>>> get 280 unexpected failures.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Considering the regression tests for xor, does it
>>>>>>>>>>>>>>>>>>>>>> make sense to test reg+imm, as the avr assembler does not have xor
>>>>>>>>>>>>>>>>>>>>>> for immediate?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Thu, May 10, 2012 at 9:12 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I don't think so, but I configured llvm to support
>>>>>>>>>>>>>>>>>>>>>>> both x86 and x64, so maybe that could help, in fact I can't build clang if
>>>>>>>>>>>>>>>>>>>>>>> I don't add support for x86.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 2012/5/10 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Target: x86_64-unknown-linux-gnu
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> But I only configured for avr... Did I do something
>>>>>>>>>>>>>>>>>>>>>>>> wrong?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Thu, May 10, 2012 at 5:32 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> This is what I'm getting:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Expected Passes : 9914
>>>>>>>>>>>>>>>>>>>>>>>>> Expected Failures : 66
>>>>>>>>>>>>>>>>>>>>>>>>> Unsupported Tests : 569
>>>>>>>>>>>>>>>>>>>>>>>>> Unexpected Failures: 11
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I've seen in that file you attached that you're
>>>>>>>>>>>>>>>>>>>>>>>>> getting errors because of the target triple, errors like:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> error: unable to create target: 'No available targets are compatible with this triple, see -version for the available targets.'
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> error auto-selecting target for module 'No available targets are compatible with this triple, see -version for the available targets
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> so I guess that's the reason, so what is your
>>>>>>>>>>>>>>>>>>>>>>>>> target triple? do clang -v to get it, mine is i386-pc-linux-gnu
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/10 Borja Ferrer <bor...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Interesting, I'll check it out tomorrow to see if
>>>>>>>>>>>>>>>>>>>>>>>>>> I can find some reason behind this, because we're getting very different
>>>>>>>>>>>>>>>>>>>>>>>>>> results here.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/9 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry for my slow response.Got i working again
>>>>>>>>>>>>>>>>>>>>>>>>>>> now, thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Building with optimization disabled and
>>>>>>>>>>>>>>>>>>>>>>>>>>> assertions turned on i get:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Avr llvm+clang:
>>>>>>>>>>>>>>>>>>>>>>>>>>> Expected Passes : 6978
>>>>>>>>>>>>>>>>>>>>>>>>>>> Expected Failures : 39
>>>>>>>>>>>>>>>>>>>>>>>>>>> Unsupported Tests : 3281
>>>>>>>>>>>>>>>>>>>>>>>>>>> Unexpected Failures: 279
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> In the 279 unexpected failures for example 143
>>>>>>>>>>>>>>>>>>>>>>>>>>> of them are test/CodeGen/Generic. I'm not really sure how these tests are
>>>>>>>>>>>>>>>>>>>>>>>>>>> supposed to work? None of them seems to be using FileCheck.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> However building for msp430 seems to be giving
>>>>>>>>>>>>>>>>>>>>>>>>>>> me similar results, indicating that it is not a avr-llvm specific problem.
>>>>>>>>>>>>>>>>>>>>>>>>>>> Please see the attached output "make check-all" from avr-llvm.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 4, 2012 at 11:30 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm asking because last week you said that you
>>>>>>>>>>>>>>>>>>>>>>>>>>>> were getting +200 fails, and since I'm getting 11 I wanted to know what's
>>>>>>>>>>>>>>>>>>>>>>>>>>>> going on.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> faluco is me btw, I updated a patch today
>>>>>>>>>>>>>>>>>>>>>>>>>>>> because I got a conflict when updating my clang repo. These variables are
>>>>>>>>>>>>>>>>>>>>>>>>>>>> defined in DiagnosticSemaKinds.td so check that you have them, they come
>>>>>>>>>>>>>>>>>>>>>>>>>>>> from the flash.diff patch.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The new tests should pass. I cannot check
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> other tests now, I'm having some issues after applying the newest patches
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that came in today by faluco:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /home/nicklas/install/avr-llvm/llvm/tools/clang/lib/Sema/SemaDecl.cpp:4374:38:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> error:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> no member named
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'err_flash_variable_requires_const' in namespace
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'clang::diag'
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Diag(NewVD->getLocation(),
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> diag::err_flash_variable_requires_const);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ~~~~~~^
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /home/nicklas/install/avr-llvm/llvm/tools/clang/lib/Sema/SemaDecl.cpp:4383:38:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> error:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> no member named
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'err_flash_pointer_requires_const' in namespace
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'clang::diag'
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Diag(NewVD->getLocation(),
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> diag::err_flash_pointer_requires_const);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ~~~~~~^
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /home/nicklas/install/avr-llvm/llvm/tools/clang/lib/Sema/SemaDecl.cpp:7208:25:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> error:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> no member named
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'err_flash_pointer_requires_const' in namespace
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'clang::diag'
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Diag(NameLoc,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> diag::err_flash_pointer_requires_const);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ~~~~~~^
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Have i done something wrong?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nicklas
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 4, 2012 at 8:50 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How many tests failures are you getting now?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm getting 11, 10 from clang due to address
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> space stuff (you'll need to patch clang to get those) and 1 from llvm.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Nicklas Bo Jensen <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ah, perfect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would actually guess that you need to run
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "make check-all" before being able to test new tests individually. Sorry :)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 4, 2012 at 8:17 PM, Borja Ferrer
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nevermind, got it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> One thing, i dont have llvm-lit in that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dir, am I supposed to build llvm with an addtional param or something in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> order to get it?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Nicklas Bo Jensen <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ok, I've committed now. To only run the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AVR specific tests run something like:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ./build/Debug+Asserts/bin/llvm-lit
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> llvm/test/CodeGen/AVR/
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 4, 2012 at 1:47 PM, Borja
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ferrer <bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Oh a small one I've just noticed, leave
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> only 1 newline between tests not 2.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ok they look great now, I don't have
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> any other objections. Please commit this test to SVN, post your SF username
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> here so that Eric or John can give you commit permissions. Once it gets
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> commited I'll check if I need to add any pattern specific tests to it,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> these tests are corner cases of some instructions.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Before commiting it, remove the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> testcases dir with all the files there, and create a new one called
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> test/CodeGen/AVR, and place your file there, just to keep the same
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> structure like in llvm's repo.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> About the rest of tests to do, from
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that list remove mul and division for now, mul isn't yet implemented and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> division can come later. Sub tests should be very similar to add, then add
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> binary ops (or, and, xor). Add calling convention tests (argument passing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> through regs and stack, return values for each value type, calls). Memory
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> operations, etc...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are quite a few tests to add, but
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for now do the sub and binary op tests and we'll discuss the others by then.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Nicklas Bo Jensen <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1) Sure
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2) Yes, I've followed the msp430
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> backend that does include it. I've removed it now.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3) Again, I've moved the CHECK lines,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> but it differs from backend to backend.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 4) Done
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 5) Done
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 6) Done
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I will continue working other tests,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which do we need? Something like(and please add/comment):
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -Sub
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -division(Only working for multiples
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of 2?)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -mult
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -Return argument(In a few variants)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -xor
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -increment
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -branching?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Any ideas?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nicklas
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, May 2, 2012 at 12:29 AM, Borja
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ferrer <bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Obviously in the last line I meant
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> adiw or subi/sbci pair, add for immediates doesn't exist for imms greater
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> than 63
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/2 Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> They look good, very nice :)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Some small details and nitpicks:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1) I think it's not necessary to add
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the reg_reg_imm variant because you covered it with the other two tests.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2) Do the tests work if you remove
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the target triple line? I've seen other backends don't include it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3) Move the CHECK lines after the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> function prototype like other backends do.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 4) In every CHECK line, can you
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> remove the tabs between the instr mnemonic and the first operand and add a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> single space? (I'm unsure about this because i dont know if CHECK eats
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> spaces). Also for the future, the llvm coding standards says to config your
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> editor to replace tabs with spaces, so it's a good moment time to do it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 5) Oh and the most important one,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> please add this in only one file, add.ll or something like that, so we can
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> keep this convention in the future, otherwise we'll end having too many
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> test files.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Something that should be covered is,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when doing 16 bit additions we can use adiw or add depending on the imm
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> value, can you cover this aswell?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/1 John Myers <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ato...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sun, Apr 29, 2012 at 10:46 AM,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nicklas Bo Jensen <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nbj...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> avr-llvm produces GNU assembler
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> syntax, which is different then the Atmel assembler syntax.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Eventually we could support
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> multiple asm syntax's like the X86 target does.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
|
