Menu
▾
▴
Re: [avr-llvm-devel] Regression tests
|
From: Borja F. <bor...@gm...> - 2012-05-24 21:51:17
|
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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
|
