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