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