|
From: Nicklas Bo J. <nbj...@gm...> - 2012-05-24 07:43:29
|
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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
|