Menu
▾
▴
Re: [avr-llvm-devel] Regression tests
|
From: Nicklas Bo J. <nbj...@gm...> - 2012-05-24 21:34:23
|
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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
|
