Re: [avr-llvm-devel] Regression tests

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

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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>