Menu
▾
▴
avr-llvm-devel — Developers mailing list.
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(26) |
Dec
(15) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(14) |
Oct
(16) |
Nov
(36) |
Dec
(3) |
| 2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
(17) |
May
(9) |
Jun
(6) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(4) |
| 2012 |
Jan
(22) |
Feb
(12) |
Mar
(39) |
Apr
(31) |
May
(42) |
Jun
(35) |
Jul
(32) |
Aug
(2) |
Sep
(5) |
Oct
|
Nov
|
Dec
(9) |
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(121) |
Jul
(61) |
Aug
(7) |
Sep
(8) |
Oct
(6) |
Nov
|
Dec
(1) |
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Nicklas Bo J. <nbj...@gm...> - 2012-06-18 07:58:08
|
I've committed the updated tests, excluding mem.ll awaiting your feedback on it (Besides not using immediate 0). On Mon, Jun 18, 2012 at 1:10 AM, Borja Ferrer <bor...@gm...> wrote: > return test: > 1) you can remove the @return8_reg() test since it's completely commented > out. > 2) in return64_arg2 you're always going to push r29:r28 as we disccused in > a previous email, so you can remove the SPLOW/HI vars, also SP is going to > be always the Y reg pair. Using Z here would be a bug. > 3) in return64_trunc same as in point 2. > 4) add a :TODO: test returning byval structs. > > call test: > 1) in the icall test, the code you're testing is a bit fragile. Basically > if you run it with -O3 it will get optimized away and you wont get an > icall. Instead, generate the icall using a function pointer from an > incoming argument. > 2) do the same as in 1 but passing an argument to the icall (any data type > will do). (remember i had to fix this last week, so testing it is imporant > in case it breaks again in the future) > 3) do the same as in 1 using the return value of the icall (any data type > will do). > > One general thing concerning all written tests up to now, can you change > all imm values (including the ones already commited), so that you don't > test things like "ldi reg, 0". So for a 16bit type instead of using a 5 use > a value were none of the registers are zero like 0xABCD instead of 0x0005 > where the hi part is 0. In the future we'll add an optimization that relies > on r0 having a 0, so many tests will break because of this since we could > get a mov reg, r0 instead of an ldi. > > I'll reply tomorrow with comments about the memory tests. > > > 2012/6/17 Borja Ferrer <bor...@gm...> > >> Thanks, I'm reviewing them now >> >> El viernes, 15 de junio de 2012, Nicklas Bo Jensen escribió: >> >> Hi, >>> >>> Please review these tests. >>> >>> Any comments? >>> >>> On Wed, Jun 6, 2012 at 2:46 AM, Borja Ferrer <bor...@gm...>wrote: >>> >>> Fixed in SVN, let me know any other issues. Thanks for reporting it! >>> >>> >>> 2012/6/5 Borja Ferrer <bor...@gm...> >>> >>> Something has changed in llvm or maybe it never worked, can't remember, >>> but I'm unable to pass arguments through an icall, I'm investigating for a >>> fix. In the meantime you can disable that assertion until I come with a >>> proper fix. >>> >>> >>> 2012/6/4 Borja Ferrer <bor...@gm...> >>> >>> I'll take a look to it shortly. >>> >>> >>> 2012/6/3 Nicklas Bo Jensen <nbj...@gm...> >>> >>> Ok. Sure your explanations are really clear :) Thanks! >>> >>> I'm having some trouble testing icall, which i'm doing using a function >>> pointer. I've attached a small C example, the corresponding cleaned up llvm >>> code and the output of running llc on it. There is a failed assertion. >>> >>> Any thoughts? >>> >>> On Fri, Jun 1, 2012 at 7:04 PM, Borja Ferrer <bor...@gm...>wrote: >>> >>> Just checking for the sub instructions that allocate and restore the >>> stack should be enough, also check that the allocated size is correct, the >>> rest of stuff can be omitted. I would also check the whole sequence >>> including the interrupt instructions in a single test, no need to do it >>> everywhere. When we get to test allocas we'll have to test for prologue and >>> epilogue code, which is very similar to the one you're seeing here. >>> About testing push and pops: no need to test that, it's part of the >>> prologue/epilogue of the function, so it's not related to calls, also, that >>> is handled by llvm so I wouldn't test that at all. Remember to test the >>> icall instruction, as far as I remember it needs to be tweaked because for >>> now it doesn't save the registers between calls like regular calls do. >>> >>> Ok, memory instructions, most of the instructions you see in that file >>> that end up with a "w" are pseudo instructions (excluding sbiw/adiw, movw >>> or other real ones that work with 16bit data) meaning that they dont get >>> into the final assembly since they don't exist in the instruction set. It's >>> a trick to make llvm think they're supported instructions that way, movws >>> and the real 16bit insts get generated, however these pseudo ops get >>> expanded into 8bit ops, that's why you wont never see those in the final >>> assembly, and if you ever see one then it's a bug. So if you do an and with >>> 16bit types, llvm selects the andw pseudo op, and a later pass expands it >>> into two real 8bit and insts that are supported by the avr inst set, dont' >>> know if this makes things clear. >>> >>> >>> 2012/5/31 Nicklas Bo Jensen <nbj...@gm...> >>> >>> Checking for stack allocation and restore could be something like: >>> >>> ; CHECK: in [[REG1:r[0-9]+]], 61 >>> ; CHECK: in [[REG2:r[0-9]+]], 62 >>> ; CHECK: sbiw [[REG2]]:[[REG1]], 4 >>> ; CHECK: out 62, [[REG2]] >>> ; CHECK: out 61, [[REG1]] >>> ; ... other tests >>> ; CHECK: in [[REG1:r[0-9]+]], 61 >>> ; CHECK: in [[REG2:r[0-9]+]], 62 >>> ; CHECK: subi [[REG1]], 254 >>> ; CHECK: sbci [[REG2]], 255 >>> ; CHECK: out 62, [[REG2]] >>> ; CHECK: out 61, [[REG1]] >>> >>> Is it something like that you have in mind? Should disabling and >>> enabling interupts (cli+writeback of SREG) also be tested? >>> >>> Checkin >>> >>> > |
|
From: Borja F. <bor...@gm...> - 2012-06-17 23:10:38
|
return test: 1) you can remove the @return8_reg() test since it's completely commented out. 2) in return64_arg2 you're always going to push r29:r28 as we disccused in a previous email, so you can remove the SPLOW/HI vars, also SP is going to be always the Y reg pair. Using Z here would be a bug. 3) in return64_trunc same as in point 2. 4) add a :TODO: test returning byval structs. call test: 1) in the icall test, the code you're testing is a bit fragile. Basically if you run it with -O3 it will get optimized away and you wont get an icall. Instead, generate the icall using a function pointer from an incoming argument. 2) do the same as in 1 but passing an argument to the icall (any data type will do). (remember i had to fix this last week, so testing it is imporant in case it breaks again in the future) 3) do the same as in 1 using the return value of the icall (any data type will do). One general thing concerning all written tests up to now, can you change all imm values (including the ones already commited), so that you don't test things like "ldi reg, 0". So for a 16bit type instead of using a 5 use a value were none of the registers are zero like 0xABCD instead of 0x0005 where the hi part is 0. In the future we'll add an optimization that relies on r0 having a 0, so many tests will break because of this since we could get a mov reg, r0 instead of an ldi. I'll reply tomorrow with comments about the memory tests. 2012/6/17 Borja Ferrer <bor...@gm...> > Thanks, I'm reviewing them now > > El viernes, 15 de junio de 2012, Nicklas Bo Jensen escribió: > > Hi, >> >> Please review these tests. >> >> Any comments? >> >> On Wed, Jun 6, 2012 at 2:46 AM, Borja Ferrer <bor...@gm...>wrote: >> >> Fixed in SVN, let me know any other issues. Thanks for reporting it! >> >> >> 2012/6/5 Borja Ferrer <bor...@gm...> >> >> Something has changed in llvm or maybe it never worked, can't remember, >> but I'm unable to pass arguments through an icall, I'm investigating for a >> fix. In the meantime you can disable that assertion until I come with a >> proper fix. >> >> >> 2012/6/4 Borja Ferrer <bor...@gm...> >> >> I'll take a look to it shortly. >> >> >> 2012/6/3 Nicklas Bo Jensen <nbj...@gm...> >> >> Ok. Sure your explanations are really clear :) Thanks! >> >> I'm having some trouble testing icall, which i'm doing using a function >> pointer. I've attached a small C example, the corresponding cleaned up llvm >> code and the output of running llc on it. There is a failed assertion. >> >> Any thoughts? >> >> On Fri, Jun 1, 2012 at 7:04 PM, Borja Ferrer <bor...@gm...>wrote: >> >> Just checking for the sub instructions that allocate and restore the >> stack should be enough, also check that the allocated size is correct, the >> rest of stuff can be omitted. I would also check the whole sequence >> including the interrupt instructions in a single test, no need to do it >> everywhere. When we get to test allocas we'll have to test for prologue and >> epilogue code, which is very similar to the one you're seeing here. >> About testing push and pops: no need to test that, it's part of the >> prologue/epilogue of the function, so it's not related to calls, also, that >> is handled by llvm so I wouldn't test that at all. Remember to test the >> icall instruction, as far as I remember it needs to be tweaked because for >> now it doesn't save the registers between calls like regular calls do. >> >> Ok, memory instructions, most of the instructions you see in that file >> that end up with a "w" are pseudo instructions (excluding sbiw/adiw, movw >> or other real ones that work with 16bit data) meaning that they dont get >> into the final assembly since they don't exist in the instruction set. It's >> a trick to make llvm think they're supported instructions that way, movws >> and the real 16bit insts get generated, however these pseudo ops get >> expanded into 8bit ops, that's why you wont never see those in the final >> assembly, and if you ever see one then it's a bug. So if you do an and with >> 16bit types, llvm selects the andw pseudo op, and a later pass expands it >> into two real 8bit and insts that are supported by the avr inst set, dont' >> know if this makes things clear. >> >> >> 2012/5/31 Nicklas Bo Jensen <nbj...@gm...> >> >> Checking for stack allocation and restore could be something like: >> >> ; CHECK: in [[REG1:r[0-9]+]], 61 >> ; CHECK: in [[REG2:r[0-9]+]], 62 >> ; CHECK: sbiw [[REG2]]:[[REG1]], 4 >> ; CHECK: out 62, [[REG2]] >> ; CHECK: out 61, [[REG1]] >> ; ... other tests >> ; CHECK: in [[REG1:r[0-9]+]], 61 >> ; CHECK: in [[REG2:r[0-9]+]], 62 >> ; CHECK: subi [[REG1]], 254 >> ; CHECK: sbci [[REG2]], 255 >> ; CHECK: out 62, [[REG2]] >> ; CHECK: out 61, [[REG1]] >> >> Is it something like that you have in mind? Should disabling and enabling >> interupts (cli+writeback of SREG) also be tested? >> >> Checkin >> >> |
|
From: Borja F. <bor...@gm...> - 2012-06-17 18:11:30
|
Thanks, I'm reviewing them now El viernes, 15 de junio de 2012, Nicklas Bo Jensen escribió: > Hi, > > Please review these tests. > > Any comments? > > On Wed, Jun 6, 2012 at 2:46 AM, Borja Ferrer <bor...@gm...>wrote: > > Fixed in SVN, let me know any other issues. Thanks for reporting it! > > > 2012/6/5 Borja Ferrer <bor...@gm...> > > Something has changed in llvm or maybe it never worked, can't remember, > but I'm unable to pass arguments through an icall, I'm investigating for a > fix. In the meantime you can disable that assertion until I come with a > proper fix. > > > 2012/6/4 Borja Ferrer <bor...@gm...> > > I'll take a look to it shortly. > > > 2012/6/3 Nicklas Bo Jensen <nbj...@gm...> > > Ok. Sure your explanations are really clear :) Thanks! > > I'm having some trouble testing icall, which i'm doing using a function > pointer. I've attached a small C example, the corresponding cleaned up llvm > code and the output of running llc on it. There is a failed assertion. > > Any thoughts? > > On Fri, Jun 1, 2012 at 7:04 PM, Borja Ferrer <bor...@gm...>wrote: > > Just checking for the sub instructions that allocate and restore the stack > should be enough, also check that the allocated size is correct, the rest > of stuff can be omitted. I would also check the whole sequence including > the interrupt instructions in a single test, no need to do it everywhere. > When we get to test allocas we'll have to test for prologue and epilogue > code, which is very similar to the one you're seeing here. > About testing push and pops: no need to test that, it's part of the > prologue/epilogue of the function, so it's not related to calls, also, that > is handled by llvm so I wouldn't test that at all. Remember to test the > icall instruction, as far as I remember it needs to be tweaked because for > now it doesn't save the registers between calls like regular calls do. > > Ok, memory instructions, most of the instructions you see in that file > that end up with a "w" are pseudo instructions (excluding sbiw/adiw, movw > or other real ones that work with 16bit data) meaning that they dont get > into the final assembly since they don't exist in the instruction set. It's > a trick to make llvm think they're supported instructions that way, movws > and the real 16bit insts get generated, however these pseudo ops get > expanded into 8bit ops, that's why you wont never see those in the final > assembly, and if you ever see one then it's a bug. So if you do an and with > 16bit types, llvm selects the andw pseudo op, and a later pass expands it > into two real 8bit and insts that are supported by the avr inst set, dont' > know if this makes things clear. > > > 2012/5/31 Nicklas Bo Jensen <nbj...@gm...> > > Checking for stack allocation and restore could be something like: > > ; CHECK: in [[REG1:r[0-9]+]], 61 > ; CHECK: in [[REG2:r[0-9]+]], 62 > ; CHECK: sbiw [[REG2]]:[[REG1]], 4 > ; CHECK: out 62, [[REG2]] > ; CHECK: out 61, [[REG1]] > ; ... other tests > ; CHECK: in [[REG1:r[0-9]+]], 61 > ; CHECK: in [[REG2:r[0-9]+]], 62 > ; CHECK: subi [[REG1]], 254 > ; CHECK: sbci [[REG2]], 255 > ; CHECK: out 62, [[REG2]] > ; CHECK: out 61, [[REG1]] > > Is it something like that you have in mind? Should disabling and enabling > interupts (cli+writeback of SREG) also be tested? > > Checkin > > |
|
From: Hannes W. <han...@ma...> - 2012-06-07 19:30:04
|
Am 07.06.2012 um 19:58 schrieb John Myers: > Hi Hannes, > > You can just delete the projects/sample folder to get it to compile. > The SVN trunk is the recommended version. > > --John Thank you for your quick reply. I had to merge some parts of the patches manually (don't know why - they seemed fine), but then everything worked. Best regards, Hannes |
|
From: John M. <ato...@gm...> - 2012-06-07 17:59:02
|
Hi Hannes, You can just delete the projects/sample folder to get it to compile. The SVN trunk is the recommended version. --John On Thu, Jun 7, 2012 at 9:43 AM, Hannes Weisbach < han...@ma...> wrote: > Hello avr-llvm developers, > > I just tried to build avr-llvm as described in gettingstarted.html, > however I ran across some problems: > > The patches from avr-llvm (cat ../avr-llvm/patches/*.diff | patch -p0) did > not apply cleanly: > RegAllocGreedy.diff was missing some path information (lib/CodeGen/), but > I told patch manually, which file to use. > > After that, I ran configure, like described in the tutorial > (../llvm/configure --prefix=$HOME/usr/avr-llvm/ --disable-optimized > --enable-targets=avr), however it seems this configure-script calls another > script, which is not properly patched because it does not know the "avr" > target. > The second configure script is called with the following line: > ./../../llvm/projects/sample/configure --disable-option-checking > '--prefix=/Users/hannesweisbach/usr/avr-llvm' '--disable-optimized' > '--enable-targets=avr' 'CFLAGS=-L/opt/local/lib -I/opt/local/include' > --cache-file=/dev/null --srcdir=../../../llvm/projects/sample > [...] > configure: error: Unrecognized target avr > configure: error: ../../../llvm/projects/sample/configure failed for > projects/sample > > I added the "avr" target manually, but the build fails (as expected) after > throwing a lot of errors like this one: > llvm-build: error: invalid target to enable: 'AVR' (not in project) > > So my question is: Can avr-llvm be used with any version of llvm and, if > not, what is the recommended version of llvm to use with avr-llvm (svn > revision or release)? > > Thanks in advance, > > Hannes > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > avr-llvm-devel mailing list > avr...@li... > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel > |
|
From: Hannes W. <han...@ma...> - 2012-06-07 17:05:33
|
Hello avr-llvm developers, I just tried to build avr-llvm as described in gettingstarted.html, however I ran across some problems: The patches from avr-llvm (cat ../avr-llvm/patches/*.diff | patch -p0) did not apply cleanly: RegAllocGreedy.diff was missing some path information (lib/CodeGen/), but I told patch manually, which file to use. After that, I ran configure, like described in the tutorial (../llvm/configure --prefix=$HOME/usr/avr-llvm/ --disable-optimized --enable-targets=avr), however it seems this configure-script calls another script, which is not properly patched because it does not know the "avr" target. The second configure script is called with the following line: ./../../llvm/projects/sample/configure --disable-option-checking '--prefix=/Users/hannesweisbach/usr/avr-llvm' '--disable-optimized' '--enable-targets=avr' 'CFLAGS=-L/opt/local/lib -I/opt/local/include' --cache-file=/dev/null --srcdir=../../../llvm/projects/sample [...] configure: error: Unrecognized target avr configure: error: ../../../llvm/projects/sample/configure failed for projects/sample I added the "avr" target manually, but the build fails (as expected) after throwing a lot of errors like this one: llvm-build: error: invalid target to enable: 'AVR' (not in project) So my question is: Can avr-llvm be used with any version of llvm and, if not, what is the recommended version of llvm to use with avr-llvm (svn revision or release)? Thanks in advance, Hannes |
|
From: Borja F. <bor...@gm...> - 2012-06-06 00:46:07
|
Fixed in SVN, let me know any other issues. Thanks for reporting it! 2012/6/5 Borja Ferrer <bor...@gm...> > Something has changed in llvm or maybe it never worked, can't remember, > but I'm unable to pass arguments through an icall, I'm investigating for a > fix. In the meantime you can disable that assertion until I come with a > proper fix. > > > 2012/6/4 Borja Ferrer <bor...@gm...> > >> I'll take a look to it shortly. >> >> >> 2012/6/3 Nicklas Bo Jensen <nbj...@gm...> >> >>> Ok. Sure your explanations are really clear :) Thanks! >>> >>> I'm having some trouble testing icall, which i'm doing using a function >>> pointer. I've attached a small C example, the corresponding cleaned up llvm >>> code and the output of running llc on it. There is a failed assertion. >>> >>> Any thoughts? >>> >>> On Fri, Jun 1, 2012 at 7:04 PM, Borja Ferrer <bor...@gm...>wrote: >>> >>>> Just checking for the sub instructions that allocate and restore the >>>> stack should be enough, also check that the allocated size is correct, the >>>> rest of stuff can be omitted. I would also check the whole sequence >>>> including the interrupt instructions in a single test, no need to do it >>>> everywhere. When we get to test allocas we'll have to test for prologue and >>>> epilogue code, which is very similar to the one you're seeing here. >>>> About testing push and pops: no need to test that, it's part of the >>>> prologue/epilogue of the function, so it's not related to calls, also, that >>>> is handled by llvm so I wouldn't test that at all. Remember to test the >>>> icall instruction, as far as I remember it needs to be tweaked because for >>>> now it doesn't save the registers between calls like regular calls do. >>>> >>>> Ok, memory instructions, most of the instructions you see in that file >>>> that end up with a "w" are pseudo instructions (excluding sbiw/adiw, movw >>>> or other real ones that work with 16bit data) meaning that they dont get >>>> into the final assembly since they don't exist in the instruction set. It's >>>> a trick to make llvm think they're supported instructions that way, movws >>>> and the real 16bit insts get generated, however these pseudo ops get >>>> expanded into 8bit ops, that's why you wont never see those in the final >>>> assembly, and if you ever see one then it's a bug. So if you do an and with >>>> 16bit types, llvm selects the andw pseudo op, and a later pass expands it >>>> into two real 8bit and insts that are supported by the avr inst set, dont' >>>> know if this makes things clear. >>>> >>>> >>>> 2012/5/31 Nicklas Bo Jensen <nbj...@gm...> >>>> >>>>> Checking for stack allocation and restore could be something like: >>>>> >>>>> ; CHECK: in [[REG1:r[0-9]+]], 61 >>>>> ; CHECK: in [[REG2:r[0-9]+]], 62 >>>>> ; CHECK: sbiw [[REG2]]:[[REG1]], 4 >>>>> ; CHECK: out 62, [[REG2]] >>>>> ; CHECK: out 61, [[REG1]] >>>>> ; ... other tests >>>>> ; CHECK: in [[REG1:r[0-9]+]], 61 >>>>> ; CHECK: in [[REG2:r[0-9]+]], 62 >>>>> ; CHECK: subi [[REG1]], 254 >>>>> ; CHECK: sbci [[REG2]], 255 >>>>> ; CHECK: out 62, [[REG2]] >>>>> ; CHECK: out 61, [[REG1]] >>>>> >>>>> Is it something like that you have in mind? Should disabling and >>>>> enabling interupts (cli+writeback of SREG) also be tested? >>>>> >>>>> Checking for the push and pops is going to be very fragile I think. >>>>> >>>>> Other backends have less thorough tests, but a bit alike, e.g. MBlaze >>>>> in test/CodeGen/MBlaze/cc.ll. Here they do tests that registers are passed >>>>> and returned in the correct registers or passed on the stack if needed. >>>>> >>>>> I've come quite far with memory operations, and have noticed the >>>>> operations stsw and lddw in AVRInstrInfo.td, however I cannot find these in >>>>> the Atmel AVR Instruction Set and cannot make llvm generate them. Could you >>>>> give me a hint to why this is? >>>>> >>>>> On Thu, May 31, 2012 at 1:24 PM, Borja Ferrer <bor...@gm...>wrote: >>>>> >>>>>> They look very good. Yes, the order of loads is an issue, I don't >>>>>> know how fragile this can get in case there are future changes that could >>>>>> alter the order. Also it could be nice to check for stack allocation and >>>>>> restore, have you checked if it's possible to do it? Add a TODO in the file >>>>>> for args and for calls for testing for structs, this is something >>>>>> unimplemented that needs to gets covered, I don't know yet any conventions >>>>>> for those. >>>>>> >>>>>> One last thing, what do other backends do to cover these tests? >>>>>> Anything similar to what we do? >>>>>> >>>>>> >>>>>> >>>>>> 2012/5/30 Nicklas Bo Jensen <nbj...@gm...> >>>>>> >>>>>>> Thanks for your explanation, it's clear. >>>>>>> >>>>>>> After a few days on holiday, I've worked on testing the calling part >>>>>>> of the calling convention. Please see the attached file. >>>>>>> >>>>>>> I'm testing only passing parameters in the registers and on the >>>>>>> stack. I'ts a bit hard to test in a good way, as for example the order of >>>>>>> loads might be different, breaking the tests without having invalid code. >>>>>>> I've tried to only tests the essentials in each case. Any comments or ideas >>>>>>> for further tests? >>>>>>> >>>>>>> >>>>>>> On Sat, May 26, 2012 at 6:28 PM, Borja Ferrer <bor...@gm... >>>>>>> > wrote: >>>>>>> >>>>>>>> About point 2: >>>>>>>> As the calling convention states, arguments that don't fit in >>>>>>>> registers r25 down to r8 are passed through the stack, that's why the last >>>>>>>> argument is being passed this way. If registers Y or Z are used depends on >>>>>>>> a number of conditions that are bit hard to explain, it depends if there >>>>>>>> are spilled registers, allocas, and incoming arguments in the stack. In >>>>>>>> this particular case, Y is ALWAYS used when reading incoming arguments from >>>>>>>> the stack, Z COULD be used only when passing arguments into a function >>>>>>>> call. So the difference is that Y is always used to READ incoming arguments >>>>>>>> from the stack, and Z or Y can be used to WRITE arguments on the stack as >>>>>>>> the preparation of the function call. >>>>>>>> >>>>>>>> About the code you attached I find it's correct. It's a void >>>>>>>> function so why care on computing an add instruction where its result is >>>>>>>> unused, also the return value of the called function is unused as well >>>>>>>> since the add instruction is useless. That's why you see r25:r24 being >>>>>>>> overwritten by the stack pointer so it can be restored to its original >>>>>>>> state when the function ends. >>>>>>>> This is all a bit tricky so if you dont understand feel free to >>>>>>>> ask, it's important to get it right so you can write good tests. >>>>>>>> >>>>>>>> 2012/5/25 Nicklas Bo Jensen <nbj...@gm...> >>>>>>>> >>>>>>>>> 1) The i8 @return8_reg test is fully commented out, can it be >>>>>>>>>> removed? I don't understand what you want to test here. >>>>>>>>>> >>>>>>>>> Can be removed, was not supposed to be there :) >>>>>>>>> >>>>>>>>> >>>>>>>>>> 2) In return64_arg2 the backend will always use Y to read >>>>>>>>>> arguments from the stack, so there's no need to check for Z. >>>>>>>>>> >>>>>>>>> Ah ok, is there any rule for putting them on the stack? Here it >>>>>>>>> can be both Y and Z right? >>>>>>>>> >>>>>>>>> >>>>>>>>>> About your calling tests, I can't see them xD >>>>>>>>> >>>>>>>>> Attached :) >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > |
|
From: Borja F. <bor...@gm...> - 2012-06-05 19:53:42
|
Something has changed in llvm or maybe it never worked, can't remember, but I'm unable to pass arguments through an icall, I'm investigating for a fix. In the meantime you can disable that assertion until I come with a proper fix. 2012/6/4 Borja Ferrer <bor...@gm...> > I'll take a look to it shortly. > > > 2012/6/3 Nicklas Bo Jensen <nbj...@gm...> > >> Ok. Sure your explanations are really clear :) Thanks! >> >> I'm having some trouble testing icall, which i'm doing using a function >> pointer. I've attached a small C example, the corresponding cleaned up llvm >> code and the output of running llc on it. There is a failed assertion. >> >> Any thoughts? >> >> On Fri, Jun 1, 2012 at 7:04 PM, Borja Ferrer <bor...@gm...>wrote: >> >>> Just checking for the sub instructions that allocate and restore the >>> stack should be enough, also check that the allocated size is correct, the >>> rest of stuff can be omitted. I would also check the whole sequence >>> including the interrupt instructions in a single test, no need to do it >>> everywhere. When we get to test allocas we'll have to test for prologue and >>> epilogue code, which is very similar to the one you're seeing here. >>> About testing push and pops: no need to test that, it's part of the >>> prologue/epilogue of the function, so it's not related to calls, also, that >>> is handled by llvm so I wouldn't test that at all. Remember to test the >>> icall instruction, as far as I remember it needs to be tweaked because for >>> now it doesn't save the registers between calls like regular calls do. >>> >>> Ok, memory instructions, most of the instructions you see in that file >>> that end up with a "w" are pseudo instructions (excluding sbiw/adiw, movw >>> or other real ones that work with 16bit data) meaning that they dont get >>> into the final assembly since they don't exist in the instruction set. It's >>> a trick to make llvm think they're supported instructions that way, movws >>> and the real 16bit insts get generated, however these pseudo ops get >>> expanded into 8bit ops, that's why you wont never see those in the final >>> assembly, and if you ever see one then it's a bug. So if you do an and with >>> 16bit types, llvm selects the andw pseudo op, and a later pass expands it >>> into two real 8bit and insts that are supported by the avr inst set, dont' >>> know if this makes things clear. >>> >>> >>> 2012/5/31 Nicklas Bo Jensen <nbj...@gm...> >>> >>>> Checking for stack allocation and restore could be something like: >>>> >>>> ; CHECK: in [[REG1:r[0-9]+]], 61 >>>> ; CHECK: in [[REG2:r[0-9]+]], 62 >>>> ; CHECK: sbiw [[REG2]]:[[REG1]], 4 >>>> ; CHECK: out 62, [[REG2]] >>>> ; CHECK: out 61, [[REG1]] >>>> ; ... other tests >>>> ; CHECK: in [[REG1:r[0-9]+]], 61 >>>> ; CHECK: in [[REG2:r[0-9]+]], 62 >>>> ; CHECK: subi [[REG1]], 254 >>>> ; CHECK: sbci [[REG2]], 255 >>>> ; CHECK: out 62, [[REG2]] >>>> ; CHECK: out 61, [[REG1]] >>>> >>>> Is it something like that you have in mind? Should disabling and >>>> enabling interupts (cli+writeback of SREG) also be tested? >>>> >>>> Checking for the push and pops is going to be very fragile I think. >>>> >>>> Other backends have less thorough tests, but a bit alike, e.g. MBlaze >>>> in test/CodeGen/MBlaze/cc.ll. Here they do tests that registers are passed >>>> and returned in the correct registers or passed on the stack if needed. >>>> >>>> I've come quite far with memory operations, and have noticed the >>>> operations stsw and lddw in AVRInstrInfo.td, however I cannot find these in >>>> the Atmel AVR Instruction Set and cannot make llvm generate them. Could you >>>> give me a hint to why this is? >>>> >>>> On Thu, May 31, 2012 at 1:24 PM, Borja Ferrer <bor...@gm...>wrote: >>>> >>>>> They look very good. Yes, the order of loads is an issue, I don't know >>>>> how fragile this can get in case there are future changes that could alter >>>>> the order. Also it could be nice to check for stack allocation and restore, >>>>> have you checked if it's possible to do it? Add a TODO in the file for args >>>>> and for calls for testing for structs, this is something unimplemented that >>>>> needs to gets covered, I don't know yet any conventions for those. >>>>> >>>>> One last thing, what do other backends do to cover these tests? >>>>> Anything similar to what we do? >>>>> >>>>> >>>>> >>>>> 2012/5/30 Nicklas Bo Jensen <nbj...@gm...> >>>>> >>>>>> Thanks for your explanation, it's clear. >>>>>> >>>>>> After a few days on holiday, I've worked on testing the calling part >>>>>> of the calling convention. Please see the attached file. >>>>>> >>>>>> I'm testing only passing parameters in the registers and on the >>>>>> stack. I'ts a bit hard to test in a good way, as for example the order of >>>>>> loads might be different, breaking the tests without having invalid code. >>>>>> I've tried to only tests the essentials in each case. Any comments or ideas >>>>>> for further tests? >>>>>> >>>>>> >>>>>> On Sat, May 26, 2012 at 6:28 PM, Borja Ferrer <bor...@gm...>wrote: >>>>>> >>>>>>> About point 2: >>>>>>> As the calling convention states, arguments that don't fit in >>>>>>> registers r25 down to r8 are passed through the stack, that's why the last >>>>>>> argument is being passed this way. If registers Y or Z are used depends on >>>>>>> a number of conditions that are bit hard to explain, it depends if there >>>>>>> are spilled registers, allocas, and incoming arguments in the stack. In >>>>>>> this particular case, Y is ALWAYS used when reading incoming arguments from >>>>>>> the stack, Z COULD be used only when passing arguments into a function >>>>>>> call. So the difference is that Y is always used to READ incoming arguments >>>>>>> from the stack, and Z or Y can be used to WRITE arguments on the stack as >>>>>>> the preparation of the function call. >>>>>>> >>>>>>> About the code you attached I find it's correct. It's a void >>>>>>> function so why care on computing an add instruction where its result is >>>>>>> unused, also the return value of the called function is unused as well >>>>>>> since the add instruction is useless. That's why you see r25:r24 being >>>>>>> overwritten by the stack pointer so it can be restored to its original >>>>>>> state when the function ends. >>>>>>> This is all a bit tricky so if you dont understand feel free to ask, >>>>>>> it's important to get it right so you can write good tests. >>>>>>> >>>>>>> 2012/5/25 Nicklas Bo Jensen <nbj...@gm...> >>>>>>> >>>>>>>> 1) The i8 @return8_reg test is fully commented out, can it be >>>>>>>>> removed? I don't understand what you want to test here. >>>>>>>>> >>>>>>>> Can be removed, was not supposed to be there :) >>>>>>>> >>>>>>>> >>>>>>>>> 2) In return64_arg2 the backend will always use Y to read >>>>>>>>> arguments from the stack, so there's no need to check for Z. >>>>>>>>> >>>>>>>> Ah ok, is there any rule for putting them on the stack? Here it can >>>>>>>> be both Y and Z right? >>>>>>>> >>>>>>>> >>>>>>>>> About your calling tests, I can't see them xD >>>>>>>> >>>>>>>> Attached :) >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > |
|
From: Borja F. <bor...@gm...> - 2012-06-04 11:16:43
|
I'll take a look to it shortly. 2012/6/3 Nicklas Bo Jensen <nbj...@gm...> > Ok. Sure your explanations are really clear :) Thanks! > > I'm having some trouble testing icall, which i'm doing using a function > pointer. I've attached a small C example, the corresponding cleaned up llvm > code and the output of running llc on it. There is a failed assertion. > > Any thoughts? > > On Fri, Jun 1, 2012 at 7:04 PM, Borja Ferrer <bor...@gm...>wrote: > >> Just checking for the sub instructions that allocate and restore the >> stack should be enough, also check that the allocated size is correct, the >> rest of stuff can be omitted. I would also check the whole sequence >> including the interrupt instructions in a single test, no need to do it >> everywhere. When we get to test allocas we'll have to test for prologue and >> epilogue code, which is very similar to the one you're seeing here. >> About testing push and pops: no need to test that, it's part of the >> prologue/epilogue of the function, so it's not related to calls, also, that >> is handled by llvm so I wouldn't test that at all. Remember to test the >> icall instruction, as far as I remember it needs to be tweaked because for >> now it doesn't save the registers between calls like regular calls do. >> >> Ok, memory instructions, most of the instructions you see in that file >> that end up with a "w" are pseudo instructions (excluding sbiw/adiw, movw >> or other real ones that work with 16bit data) meaning that they dont get >> into the final assembly since they don't exist in the instruction set. It's >> a trick to make llvm think they're supported instructions that way, movws >> and the real 16bit insts get generated, however these pseudo ops get >> expanded into 8bit ops, that's why you wont never see those in the final >> assembly, and if you ever see one then it's a bug. So if you do an and with >> 16bit types, llvm selects the andw pseudo op, and a later pass expands it >> into two real 8bit and insts that are supported by the avr inst set, dont' >> know if this makes things clear. >> >> >> 2012/5/31 Nicklas Bo Jensen <nbj...@gm...> >> >>> Checking for stack allocation and restore could be something like: >>> >>> ; CHECK: in [[REG1:r[0-9]+]], 61 >>> ; CHECK: in [[REG2:r[0-9]+]], 62 >>> ; CHECK: sbiw [[REG2]]:[[REG1]], 4 >>> ; CHECK: out 62, [[REG2]] >>> ; CHECK: out 61, [[REG1]] >>> ; ... other tests >>> ; CHECK: in [[REG1:r[0-9]+]], 61 >>> ; CHECK: in [[REG2:r[0-9]+]], 62 >>> ; CHECK: subi [[REG1]], 254 >>> ; CHECK: sbci [[REG2]], 255 >>> ; CHECK: out 62, [[REG2]] >>> ; CHECK: out 61, [[REG1]] >>> >>> Is it something like that you have in mind? Should disabling and >>> enabling interupts (cli+writeback of SREG) also be tested? >>> >>> Checking for the push and pops is going to be very fragile I think. >>> >>> Other backends have less thorough tests, but a bit alike, e.g. MBlaze in >>> test/CodeGen/MBlaze/cc.ll. Here they do tests that registers are passed and >>> returned in the correct registers or passed on the stack if needed. >>> >>> I've come quite far with memory operations, and have noticed the >>> operations stsw and lddw in AVRInstrInfo.td, however I cannot find these in >>> the Atmel AVR Instruction Set and cannot make llvm generate them. Could you >>> give me a hint to why this is? >>> >>> On Thu, May 31, 2012 at 1:24 PM, Borja Ferrer <bor...@gm...>wrote: >>> >>>> They look very good. Yes, the order of loads is an issue, I don't know >>>> how fragile this can get in case there are future changes that could alter >>>> the order. Also it could be nice to check for stack allocation and restore, >>>> have you checked if it's possible to do it? Add a TODO in the file for args >>>> and for calls for testing for structs, this is something unimplemented that >>>> needs to gets covered, I don't know yet any conventions for those. >>>> >>>> One last thing, what do other backends do to cover these tests? >>>> Anything similar to what we do? >>>> >>>> >>>> >>>> 2012/5/30 Nicklas Bo Jensen <nbj...@gm...> >>>> >>>>> Thanks for your explanation, it's clear. >>>>> >>>>> After a few days on holiday, I've worked on testing the calling part >>>>> of the calling convention. Please see the attached file. >>>>> >>>>> I'm testing only passing parameters in the registers and on the stack. >>>>> I'ts a bit hard to test in a good way, as for example the order of loads >>>>> might be different, breaking the tests without having invalid code. I've >>>>> tried to only tests the essentials in each case. Any comments or ideas for >>>>> further tests? >>>>> >>>>> >>>>> On Sat, May 26, 2012 at 6:28 PM, Borja Ferrer <bor...@gm...>wrote: >>>>> >>>>>> About point 2: >>>>>> As the calling convention states, arguments that don't fit in >>>>>> registers r25 down to r8 are passed through the stack, that's why the last >>>>>> argument is being passed this way. If registers Y or Z are used depends on >>>>>> a number of conditions that are bit hard to explain, it depends if there >>>>>> are spilled registers, allocas, and incoming arguments in the stack. In >>>>>> this particular case, Y is ALWAYS used when reading incoming arguments from >>>>>> the stack, Z COULD be used only when passing arguments into a function >>>>>> call. So the difference is that Y is always used to READ incoming arguments >>>>>> from the stack, and Z or Y can be used to WRITE arguments on the stack as >>>>>> the preparation of the function call. >>>>>> >>>>>> About the code you attached I find it's correct. It's a void function >>>>>> so why care on computing an add instruction where its result is unused, >>>>>> also the return value of the called function is unused as well since the >>>>>> add instruction is useless. That's why you see r25:r24 being overwritten by >>>>>> the stack pointer so it can be restored to its original state when the >>>>>> function ends. >>>>>> This is all a bit tricky so if you dont understand feel free to ask, >>>>>> it's important to get it right so you can write good tests. >>>>>> >>>>>> 2012/5/25 Nicklas Bo Jensen <nbj...@gm...> >>>>>> >>>>>>> 1) The i8 @return8_reg test is fully commented out, can it be >>>>>>>> removed? I don't understand what you want to test here. >>>>>>>> >>>>>>> Can be removed, was not supposed to be there :) >>>>>>> >>>>>>> >>>>>>>> 2) In return64_arg2 the backend will always use Y to read arguments >>>>>>>> from the stack, so there's no need to check for Z. >>>>>>>> >>>>>>> Ah ok, is there any rule for putting them on the stack? Here it can >>>>>>> be both Y and Z right? >>>>>>> >>>>>>> >>>>>>>> About your calling tests, I can't see them xD >>>>>>> >>>>>>> Attached :) >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > |
|
From: Nicklas Bo J. <nbj...@gm...> - 2012-06-03 20:46:03
|
../build/Debug+Asserts/bin/llc icall.ll -march=avr -o icall.s llc: /home/nicklas/install/avr-llvm/llvm/lib/Target/AVR/AVRISelDAGToDAG.cpp:287: virtual llvm::SDNode *<anonymous namespace>::AVRDAGToDAGISel::Select(llvm::SDNode *): Assertion `Callee.getOpcode() == ISD::CopyFromReg && "Unknown callee source"' failed. 0 llc 0x000000000138ff8e 1 llc 0x000000000139048a 2 libpthread.so.0 0x00007f4b19bc0cb0 3 libc.so.6 0x00007f4b18e16445 gsignal + 53 4 libc.so.6 0x00007f4b18e19bab abort + 379 5 libc.so.6 0x00007f4b18e0f10e 6 libc.so.6 0x00007f4b18e0f1b2 7 llc 0x0000000000675f8d 8 llc 0x0000000000c852cb llvm::SelectionDAGISel::DoInstructionSelection() + 555 9 llc 0x0000000000c84979 llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 3161 10 llc 0x0000000000c83d0d llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator<llvm::Instruction const>, llvm::ilist_iterator<llvm::Instruction const>, bool&) + 253 11 llc 0x0000000000c83b82 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 3122 12 llc 0x0000000000c8233a llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 826 13 llc 0x0000000000e012fe llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 110 14 llc 0x0000000001311c86 llvm::FPPassManager::runOnFunction(llvm::Function&) + 438 15 llc 0x0000000001311fad llvm::FPPassManager::runOnModule(llvm::Module&) + 125 16 llc 0x00000000013121fd llvm::MPPassManager::runOnModule(llvm::Module&) + 493 17 llc 0x00000000013128a7 llvm::PassManagerImpl::run(llvm::Module&) + 167 18 llc 0x0000000001312a91 llvm::PassManager::run(llvm::Module&) + 33 19 llc 0x00000000005e11c7 main + 3831 20 libc.so.6 0x00007f4b18e0176d __libc_start_main + 237 21 llc 0x00000000005dedf9 Stack dump: 0. Program arguments: ../build/Debug+Asserts/bin/llc icall.ll -march=avr -o icall.s 1. Running pass 'Function Pass Manager' on module 'icall.ll'. 2. Running pass 'AVR DAG->DAG Instruction Selection' on function '@foobar' Aborted (core dumped) |
|
From: Borja F. <bor...@gm...> - 2012-06-01 17:05:05
|
Just checking for the sub instructions that allocate and restore the stack should be enough, also check that the allocated size is correct, the rest of stuff can be omitted. I would also check the whole sequence including the interrupt instructions in a single test, no need to do it everywhere. When we get to test allocas we'll have to test for prologue and epilogue code, which is very similar to the one you're seeing here. About testing push and pops: no need to test that, it's part of the prologue/epilogue of the function, so it's not related to calls, also, that is handled by llvm so I wouldn't test that at all. Remember to test the icall instruction, as far as I remember it needs to be tweaked because for now it doesn't save the registers between calls like regular calls do. Ok, memory instructions, most of the instructions you see in that file that end up with a "w" are pseudo instructions (excluding sbiw/adiw, movw or other real ones that work with 16bit data) meaning that they dont get into the final assembly since they don't exist in the instruction set. It's a trick to make llvm think they're supported instructions that way, movws and the real 16bit insts get generated, however these pseudo ops get expanded into 8bit ops, that's why you wont never see those in the final assembly, and if you ever see one then it's a bug. So if you do an and with 16bit types, llvm selects the andw pseudo op, and a later pass expands it into two real 8bit and insts that are supported by the avr inst set, dont' know if this makes things clear. 2012/5/31 Nicklas Bo Jensen <nbj...@gm...> > Checking for stack allocation and restore could be something like: > > ; CHECK: in [[REG1:r[0-9]+]], 61 > ; CHECK: in [[REG2:r[0-9]+]], 62 > ; CHECK: sbiw [[REG2]]:[[REG1]], 4 > ; CHECK: out 62, [[REG2]] > ; CHECK: out 61, [[REG1]] > ; ... other tests > ; CHECK: in [[REG1:r[0-9]+]], 61 > ; CHECK: in [[REG2:r[0-9]+]], 62 > ; CHECK: subi [[REG1]], 254 > ; CHECK: sbci [[REG2]], 255 > ; CHECK: out 62, [[REG2]] > ; CHECK: out 61, [[REG1]] > > Is it something like that you have in mind? Should disabling and enabling > interupts (cli+writeback of SREG) also be tested? > > Checking for the push and pops is going to be very fragile I think. > > Other backends have less thorough tests, but a bit alike, e.g. MBlaze in > test/CodeGen/MBlaze/cc.ll. Here they do tests that registers are passed and > returned in the correct registers or passed on the stack if needed. > > I've come quite far with memory operations, and have noticed the > operations stsw and lddw in AVRInstrInfo.td, however I cannot find these in > the Atmel AVR Instruction Set and cannot make llvm generate them. Could you > give me a hint to why this is? > > On Thu, May 31, 2012 at 1:24 PM, Borja Ferrer <bor...@gm...>wrote: > >> They look very good. Yes, the order of loads is an issue, I don't know >> how fragile this can get in case there are future changes that could alter >> the order. Also it could be nice to check for stack allocation and restore, >> have you checked if it's possible to do it? Add a TODO in the file for args >> and for calls for testing for structs, this is something unimplemented that >> needs to gets covered, I don't know yet any conventions for those. >> >> One last thing, what do other backends do to cover these tests? Anything >> similar to what we do? >> >> >> >> 2012/5/30 Nicklas Bo Jensen <nbj...@gm...> >> >>> Thanks for your explanation, it's clear. >>> >>> After a few days on holiday, I've worked on testing the calling part of >>> the calling convention. Please see the attached file. >>> >>> I'm testing only passing parameters in the registers and on the stack. >>> I'ts a bit hard to test in a good way, as for example the order of loads >>> might be different, breaking the tests without having invalid code. I've >>> tried to only tests the essentials in each case. Any comments or ideas for >>> further tests? >>> >>> >>> On Sat, May 26, 2012 at 6:28 PM, Borja Ferrer <bor...@gm...>wrote: >>> >>>> About point 2: >>>> As the calling convention states, arguments that don't fit in registers >>>> r25 down to r8 are passed through the stack, that's why the last argument >>>> is being passed this way. If registers Y or Z are used depends on a number >>>> of conditions that are bit hard to explain, it depends if there are spilled >>>> registers, allocas, and incoming arguments in the stack. In this particular >>>> case, Y is ALWAYS used when reading incoming arguments from the stack, Z >>>> COULD be used only when passing arguments into a function call. So the >>>> difference is that Y is always used to READ incoming arguments from the >>>> stack, and Z or Y can be used to WRITE arguments on the stack as the >>>> preparation of the function call. >>>> >>>> About the code you attached I find it's correct. It's a void function >>>> so why care on computing an add instruction where its result is unused, >>>> also the return value of the called function is unused as well since the >>>> add instruction is useless. That's why you see r25:r24 being overwritten by >>>> the stack pointer so it can be restored to its original state when the >>>> function ends. >>>> This is all a bit tricky so if you dont understand feel free to ask, >>>> it's important to get it right so you can write good tests. >>>> >>>> 2012/5/25 Nicklas Bo Jensen <nbj...@gm...> >>>> >>>>> 1) The i8 @return8_reg test is fully commented out, can it be removed? >>>>>> I don't understand what you want to test here. >>>>>> >>>>> Can be removed, was not supposed to be there :) >>>>> >>>>> >>>>>> 2) In return64_arg2 the backend will always use Y to read arguments >>>>>> from the stack, so there's no need to check for Z. >>>>>> >>>>> Ah ok, is there any rule for putting them on the stack? Here it can be >>>>> both Y and Z right? >>>>> >>>>> >>>>>> About your calling tests, I can't see them xD >>>>> >>>>> Attached :) >>>>> >>>> >>>> >>> >> > |
|
From: Nicklas Bo J. <nbj...@gm...> - 2012-05-31 13:58:30
|
Checking for stack allocation and restore could be something like: ; CHECK: in [[REG1:r[0-9]+]], 61 ; CHECK: in [[REG2:r[0-9]+]], 62 ; CHECK: sbiw [[REG2]]:[[REG1]], 4 ; CHECK: out 62, [[REG2]] ; CHECK: out 61, [[REG1]] ; ... other tests ; CHECK: in [[REG1:r[0-9]+]], 61 ; CHECK: in [[REG2:r[0-9]+]], 62 ; CHECK: subi [[REG1]], 254 ; CHECK: sbci [[REG2]], 255 ; CHECK: out 62, [[REG2]] ; CHECK: out 61, [[REG1]] Is it something like that you have in mind? Should disabling and enabling interupts (cli+writeback of SREG) also be tested? Checking for the push and pops is going to be very fragile I think. Other backends have less thorough tests, but a bit alike, e.g. MBlaze in test/CodeGen/MBlaze/cc.ll. Here they do tests that registers are passed and returned in the correct registers or passed on the stack if needed. I've come quite far with memory operations, and have noticed the operations stsw and lddw in AVRInstrInfo.td, however I cannot find these in the Atmel AVR Instruction Set and cannot make llvm generate them. Could you give me a hint to why this is? On Thu, May 31, 2012 at 1:24 PM, Borja Ferrer <bor...@gm...> wrote: > They look very good. Yes, the order of loads is an issue, I don't know how > fragile this can get in case there are future changes that could alter the > order. Also it could be nice to check for stack allocation and restore, > have you checked if it's possible to do it? Add a TODO in the file for args > and for calls for testing for structs, this is something unimplemented that > needs to gets covered, I don't know yet any conventions for those. > > One last thing, what do other backends do to cover these tests? Anything > similar to what we do? > > > > 2012/5/30 Nicklas Bo Jensen <nbj...@gm...> > >> Thanks for your explanation, it's clear. >> >> After a few days on holiday, I've worked on testing the calling part of >> the calling convention. Please see the attached file. >> >> I'm testing only passing parameters in the registers and on the stack. >> I'ts a bit hard to test in a good way, as for example the order of loads >> might be different, breaking the tests without having invalid code. I've >> tried to only tests the essentials in each case. Any comments or ideas for >> further tests? >> >> >> On Sat, May 26, 2012 at 6:28 PM, Borja Ferrer <bor...@gm...>wrote: >> >>> About point 2: >>> As the calling convention states, arguments that don't fit in registers >>> r25 down to r8 are passed through the stack, that's why the last argument >>> is being passed this way. If registers Y or Z are used depends on a number >>> of conditions that are bit hard to explain, it depends if there are spilled >>> registers, allocas, and incoming arguments in the stack. In this particular >>> case, Y is ALWAYS used when reading incoming arguments from the stack, Z >>> COULD be used only when passing arguments into a function call. So the >>> difference is that Y is always used to READ incoming arguments from the >>> stack, and Z or Y can be used to WRITE arguments on the stack as the >>> preparation of the function call. >>> >>> About the code you attached I find it's correct. It's a void function so >>> why care on computing an add instruction where its result is unused, also >>> the return value of the called function is unused as well since the add >>> instruction is useless. That's why you see r25:r24 being overwritten by the >>> stack pointer so it can be restored to its original state when the function >>> ends. >>> This is all a bit tricky so if you dont understand feel free to ask, >>> it's important to get it right so you can write good tests. >>> >>> 2012/5/25 Nicklas Bo Jensen <nbj...@gm...> >>> >>>> 1) The i8 @return8_reg test is fully commented out, can it be removed? >>>>> I don't understand what you want to test here. >>>>> >>>> Can be removed, was not supposed to be there :) >>>> >>>> >>>>> 2) In return64_arg2 the backend will always use Y to read arguments >>>>> from the stack, so there's no need to check for Z. >>>>> >>>> Ah ok, is there any rule for putting them on the stack? Here it can be >>>> both Y and Z right? >>>> >>>> >>>>> About your calling tests, I can't see them xD >>>> >>>> Attached :) >>>> >>> >>> >> > |
|
From: Borja F. <bor...@gm...> - 2012-05-31 11:24:29
|
They look very good. Yes, the order of loads is an issue, I don't know how fragile this can get in case there are future changes that could alter the order. Also it could be nice to check for stack allocation and restore, have you checked if it's possible to do it? Add a TODO in the file for args and for calls for testing for structs, this is something unimplemented that needs to gets covered, I don't know yet any conventions for those. One last thing, what do other backends do to cover these tests? Anything similar to what we do? 2012/5/30 Nicklas Bo Jensen <nbj...@gm...> > Thanks for your explanation, it's clear. > > After a few days on holiday, I've worked on testing the calling part of > the calling convention. Please see the attached file. > > I'm testing only passing parameters in the registers and on the stack. > I'ts a bit hard to test in a good way, as for example the order of loads > might be different, breaking the tests without having invalid code. I've > tried to only tests the essentials in each case. Any comments or ideas for > further tests? > > > On Sat, May 26, 2012 at 6:28 PM, Borja Ferrer <bor...@gm...>wrote: > >> About point 2: >> As the calling convention states, arguments that don't fit in registers >> r25 down to r8 are passed through the stack, that's why the last argument >> is being passed this way. If registers Y or Z are used depends on a number >> of conditions that are bit hard to explain, it depends if there are spilled >> registers, allocas, and incoming arguments in the stack. In this particular >> case, Y is ALWAYS used when reading incoming arguments from the stack, Z >> COULD be used only when passing arguments into a function call. So the >> difference is that Y is always used to READ incoming arguments from the >> stack, and Z or Y can be used to WRITE arguments on the stack as the >> preparation of the function call. >> >> About the code you attached I find it's correct. It's a void function so >> why care on computing an add instruction where its result is unused, also >> the return value of the called function is unused as well since the add >> instruction is useless. That's why you see r25:r24 being overwritten by the >> stack pointer so it can be restored to its original state when the function >> ends. >> This is all a bit tricky so if you dont understand feel free to ask, it's >> important to get it right so you can write good tests. >> >> 2012/5/25 Nicklas Bo Jensen <nbj...@gm...> >> >>> 1) The i8 @return8_reg test is fully commented out, can it be removed? I >>>> don't understand what you want to test here. >>>> >>> Can be removed, was not supposed to be there :) >>> >>> >>>> 2) In return64_arg2 the backend will always use Y to read arguments >>>> from the stack, so there's no need to check for Z. >>>> >>> Ah ok, is there any rule for putting them on the stack? Here it can be >>> both Y and Z right? >>> >>> >>>> About your calling tests, I can't see them xD >>> >>> Attached :) >>> >> >> > |
|
From: Borja F. <bor...@gm...> - 2012-05-26 16:28:19
|
About point 2: As the calling convention states, arguments that don't fit in registers r25 down to r8 are passed through the stack, that's why the last argument is being passed this way. If registers Y or Z are used depends on a number of conditions that are bit hard to explain, it depends if there are spilled registers, allocas, and incoming arguments in the stack. In this particular case, Y is ALWAYS used when reading incoming arguments from the stack, Z COULD be used only when passing arguments into a function call. So the difference is that Y is always used to READ incoming arguments from the stack, and Z or Y can be used to WRITE arguments on the stack as the preparation of the function call. About the code you attached I find it's correct. It's a void function so why care on computing an add instruction where its result is unused, also the return value of the called function is unused as well since the add instruction is useless. That's why you see r25:r24 being overwritten by the stack pointer so it can be restored to its original state when the function ends. This is all a bit tricky so if you dont understand feel free to ask, it's important to get it right so you can write good tests. 2012/5/25 Nicklas Bo Jensen <nbj...@gm...> > 1) The i8 @return8_reg test is fully commented out, can it be removed? I >> don't understand what you want to test here. >> > Can be removed, was not supposed to be there :) > > >> 2) In return64_arg2 the backend will always use Y to read arguments from >> the stack, so there's no need to check for Z. >> > Ah ok, is there any rule for putting them on the stack? Here it can be > both Y and Z right? > > >> About your calling tests, I can't see them xD > > Attached :) > |
|
From: Borja F. <bor...@gm...> - 2012-05-25 10:41:36
|
Ok I understand it now. Some comments below:
1) The i8 @return8_reg test is fully commented out, can it be removed? I
don't understand what you want to test here.
2) In return64_arg2 the backend will always use Y to read arguments from
the stack, so there's no need to check for Z.
About your calling tests, I can't see them xD
2012/5/25 Nicklas Bo Jensen <nbj...@gm...>
> Is it more clear now? I think those tests have become too complicated and
> we should delete them for now.
>
> Also I'm seeing some wierd code for calling. I've attached a short piece
> of code showing what I think could be a bug. After call foo, we are for
> example doing "adiw r25:r24, 8", but the result from the call is stored
> in these registers. That is not optimal. Also the addition with 5 never
> happens. Is this because the function(calli64_stack) only returns void?
>
> On Fri, May 25, 2012 at 12:06 AM, Nicklas Bo Jensen <nbj...@gm...>wrote:
>
>> Ah i see. I had only implemented correct behaviour in return void, as we
>> had not decided on a test style yet, meaning that those tests for returning
>> the first argument were not testing anything. I have included a new version
>> implementing the check at all cases.
>>
>> The regex is not needed in other tests, where we are not using
>> CHECK-NEXT, as the comments are simply ignored here. When only using CHECK,
>> there can be all kind of things between two CHECK's.
>>
>> On Thu, May 24, 2012 at 11:51 PM, Borja Ferrer <bor...@gm...>wrote:
>>
>>> Yes I understood it xD
>>> What confuses me is that the first CHECK which checks the function name
>>> label has a regex (the return_void: line), while the rest of tests don't
>>> have it, meaning that the comment in the functionname label is not present
>>> OR that when you only check for ret_void: (done in the rest of tests) and
>>> then you use CHECK-NEXT it is still in the same line which doesn't make
>>> sense to me at all, but who knows.
>>>
>>> I see that the BB#0 comment is always printed, so it has to be consumed
>>> before you get into the real instructions.
>>>
>>> Basically if what i wrote is confusing, why is the first regexp needed
>>> and not needed in the rest of cases?
>>>
>>>
>>> 2012/5/24 Nicklas Bo Jensen <nbj...@gm...>
>>>
>>>> Sorry for my bad explanations :)
>>>>
>>>> For returning void and returning the first parameter directly the
>>>> assembly looks like:
>>>> return_void: # @return_void
>>>> # BB#0:
>>>> ret
>>>>
>>>> What I'm thinking is important to test in these cases is that there is
>>>> no code between the label "return_void:" and "ret", only comments.
>>>>
>>>> Here CHECK-NEXT is a good choice, but the two comments makes it much
>>>> harder to use CHECK-NEXT. Therefore the first regexp consumes the comment
>>>> after the label and the second the comment on the next line, if not
>>>> including the first regexp the second will match on the same line as the
>>>> label.
>>>>
>>>> Does that make sense? Essentially it would be much easier to test if
>>>> FileCheck had the option for ignoring comments.
>>>>
>>>>
>>>>
>>>> On Thu, May 24, 2012 at 11:03 PM, Borja Ferrer <bor...@gm...>wrote:
>>>>
>>>>> I'm a bit confused now, why is this comment only appearing in this
>>>>> test then? I mean, for the rest of tests you didn't need to add that regex.
>>>>>
>>>>>
>>>>> 2012/5/24 Nicklas Bo Jensen <nbj...@gm...>
>>>>>
>>>>>> The asm looks something like:
>>>>>> return_void: # @return_void
>>>>>> # BB#0:
>>>>>> ret
>>>>>>
>>>>>> So the two regex's handle one comment each. It's far from perfect,
>>>>>> should we just delete these testcases for now?
>>>>>>
>>>>>> On Thu, May 24, 2012 at 6:40 PM, Borja Ferrer <bor...@gm...>wrote:
>>>>>>
>>>>>>> I prefer the second, although it's a bit nasty it doesn't use an
>>>>>>> external tool. For what is this regex used in CHECK:
>>>>>>> return_void:{{[a-zA-Z0-9 #@]*}} ?
>>>>>>>
>>>>>>>
>>>>>>> 2012/5/24 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>
>>>>>>>> I agree. FileCheck should be able to ignore comments(at least as a
>>>>>>>> parameter) like it ignores whitespaces.
>>>>>>>>
>>>>>>>> However I do have a few suggestions for how to do it, if you like
>>>>>>>> one of them we can use it.
>>>>>>>>
>>>>>>>> 1. Previous suggestion with "hardcoded" comment.
>>>>>>>> 2. Accept any comment after label:
>>>>>>>> define void @return_void() {
>>>>>>>> ; CHECK: return_void:{{[a-zA-Z0-9 #@]*}}
>>>>>>>> ; CHECK-NEXT: #{{[a-zA-Z0-9 #@]*}}
>>>>>>>> ; CHECK-NEXT: ret
>>>>>>>> ret void
>>>>>>>> }
>>>>>>>>
>>>>>>>> 3. Strip the assembler for comments and blank lines(here using sed)
>>>>>>>> before checking.
>>>>>>>> ; RUN: llc < %s -march=avr | sed "s/#.*//" | sed "/^$/d" |
>>>>>>>> FileCheck %s
>>>>>>>>
>>>>>>>> define void @return_void() {
>>>>>>>> ; CHECK: return_void:
>>>>>>>> ; CHECK-NEXT: ret
>>>>>>>> ret void
>>>>>>>> }
>>>>>>>>
>>>>>>>> 2. is a bit complex and if we later choose to not print comments
>>>>>>>> before blocks the test will fail.
>>>>>>>> 3. is simpler, but requires a third party tool.
>>>>>>>>
>>>>>>>> What do you think Borja? I haven't found another backend dealing
>>>>>>>> with this issue.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, May 24, 2012 at 12:33 PM, Borja Ferrer <
>>>>>>>> bor...@gm...> wrote:
>>>>>>>>
>>>>>>>>> I like it but checking for BB#0 is a bit nasty because it's a
>>>>>>>>> comment and not an instruction, also that could change in the future
>>>>>>>>> breaking the test.
>>>>>>>>>
>>>>>>>>> I've checked the other backends and we're testing things further
>>>>>>>>> than what others do so I think there's no need for more tests there.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2012/5/24 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>
>>>>>>>>>> One idea could be to use CHECK-NEXT that checks if the string is
>>>>>>>>>> on a consecutive line, then we could do something like:
>>>>>>>>>>
>>>>>>>>>> define void @return_void() {
>>>>>>>>>> ; CHECK: return_void:
>>>>>>>>>> ; CHECK-NEXT: # BB#0:
>>>>>>>>>> ; CHECK-NEXT: ret
>>>>>>>>>> ret void
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> The solution with the comment is not the best. What do you think?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, May 24, 2012 at 1:48 AM, Borja Ferrer <
>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>
>>>>>>>>>>> Maybe you could check using CHECKNOT or whatever to make sure
>>>>>>>>>>> that no moves are emitted, that would cover it.
>>>>>>>>>>>
>>>>>>>>>>> I'll check what other backends do regarding these tests and see
>>>>>>>>>>> if I can come up with further things.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2012/5/23 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>
>>>>>>>>>>>> Are the following tests obsolete, as there in my opinion is no
>>>>>>>>>>>> really good way to test them using FileCheck(with my current return
>>>>>>>>>>>> tests(included) we could return the wrong argument)?
>>>>>>>>>>>>
>>>>>>>>>>>> - Returning void.
>>>>>>>>>>>> - Returning the first parameter, which is already in the
>>>>>>>>>>>> correct place.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Do we need additional tests for returning, besides
>>>>>>>>>>>> returning immediate and argument, like returning a value from register or
>>>>>>>>>>>> is it already covered in returning a argument?
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, May 23, 2012 at 12:51 AM, Borja Ferrer <
>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, that's something handled by llvm, not the backend so we
>>>>>>>>>>>>> can't do too much there, although it would be a nice optimization to do.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2012/5/23 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for the explanation. It's clear :)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Out of curiosity, why are the pushes and pops in the example
>>>>>>>>>>>>>> below? movw leaves r17:r14 unchanged. Do we simply push and pop all
>>>>>>>>>>>>>> registers to be on the safe side and limited static analysis?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> llvm:
>>>>>>>>>>>>>> define i32 @return32_arg2(i32 %x, i32 %y, i32 %z) {
>>>>>>>>>>>>>> ret i32 %z
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> asm:
>>>>>>>>>>>>>> return32_arg2:
>>>>>>>>>>>>>> push r14
>>>>>>>>>>>>>> push r15
>>>>>>>>>>>>>> push r16
>>>>>>>>>>>>>> push r17
>>>>>>>>>>>>>> movw r23:r22, r15:r14
>>>>>>>>>>>>>> movw r25:r24, r17:r16
>>>>>>>>>>>>>> pop r17
>>>>>>>>>>>>>> pop r16
>>>>>>>>>>>>>> pop r15
>>>>>>>>>>>>>> pop r14
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, May 22, 2012 at 11:32 PM, Borja Ferrer <
>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Here you have a link that explains how registers are used:
>>>>>>>>>>>>>>> www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_reg_usage
>>>>>>>>>>>>>>> Testing a calling convention without knowing how it actually
>>>>>>>>>>>>>>> works is going to be an insane task to do xD
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> About your question, when you read that link all will become
>>>>>>>>>>>>>>> clear but basically here is what's going on. Arguments are passed from r25
>>>>>>>>>>>>>>> down to r8, since in this case three 64bit args can't fit in those
>>>>>>>>>>>>>>> registers the last argument is passed through the stack, so you get:
>>>>>>>>>>>>>>> arg1 is in: r25-r18
>>>>>>>>>>>>>>> arg2 is in: r17-r10
>>>>>>>>>>>>>>> arg3 obviously doesn't fit in 2 register so it's all passed
>>>>>>>>>>>>>>> through the stack, thats why you get those loads. Notice that the lowest
>>>>>>>>>>>>>>> part of the argument is in Y+5 because in +4 and +3 is r29:r28 you just
>>>>>>>>>>>>>>> pushed and in +2 +1 is the the return address that was pushed into the
>>>>>>>>>>>>>>> stack after the call was performed.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Another thing, you should add checks on the pushes and pops
>>>>>>>>>>>>>>> for the callee saved registers so we're sure that they're being saved.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2012/5/22 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Perfect :)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm moving on to calling convention and have started with
>>>>>>>>>>>>>>>> return values. However I'm a bit unsure what the calling convention
>>>>>>>>>>>>>>>> actually is. For example with my last test, called "return64_arg2" in the
>>>>>>>>>>>>>>>> attached .ll file and the generated assembly in the .s file, is the correct
>>>>>>>>>>>>>>>> thing happening and how it should be tested? Couldn't we have passed the
>>>>>>>>>>>>>>>> arguments in the normal registers? I.e. r25:r2.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If the arguments don't fit in the registers, do we always
>>>>>>>>>>>>>>>> store the result in the same place in ram?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Mon, May 21, 2012 at 11:38 PM, Borja Ferrer <
>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Nice, so now you have the same test failures as me, they
>>>>>>>>>>>>>>>>> are caused because we're using custom address space stuff in clang, dont
>>>>>>>>>>>>>>>>> worry about those. Basically they fail because these tests are writing into
>>>>>>>>>>>>>>>>> address space 1 which is flash data and that is forbidden in our target
>>>>>>>>>>>>>>>>> (remember flash memory is readonly).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The test cases you just commited look great :) To which
>>>>>>>>>>>>>>>>> ones are you going to move on next?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yes, that code looks correct, where is the problem?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2012/5/21 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Is the following generated code correct:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> LLVM:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> define i8 @return8_arg(i8 %x) {
>>>>>>>>>>>>>>>>>> ret i8 %x
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Generated:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> return8_arg:
>>>>>>>>>>>>>>>>>> ret
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Something similar in .c compiling with avr-gcc gives a
>>>>>>>>>>>>>>>>>> few pushes, loads and pops.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Mon, May 21, 2012 at 10:48 PM, Nicklas Bo Jensen <
>>>>>>>>>>>>>>>>>> nbj...@gm...> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> When adding those targets I only have 10 unexpected
>>>>>>>>>>>>>>>>>>> failures:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Clang :: CodeGen/address-space-compound-literal.c
>>>>>>>>>>>>>>>>>>> Clang :: CodeGen/address-space-field1.c
>>>>>>>>>>>>>>>>>>> Clang :: CodeGen/address-space.c
>>>>>>>>>>>>>>>>>>> Clang :: CodeGenCXX/mangle-address-space.cpp
>>>>>>>>>>>>>>>>>>> Clang :: PCH/types.c
>>>>>>>>>>>>>>>>>>> Clang :: Sema/address_spaces.c
>>>>>>>>>>>>>>>>>>> Clang :: SemaCXX/address-space-conversion.cpp
>>>>>>>>>>>>>>>>>>> Clang :: SemaCXX/address-space-newdelete.cpp
>>>>>>>>>>>>>>>>>>> Clang :: SemaCXX/address-space-references.cpp
>>>>>>>>>>>>>>>>>>> Clang :: SemaTemplate/address-spaces.cpp
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I will try to run each test separately and try to figure
>>>>>>>>>>>>>>>>>>> out why they are failing. I have also attached the test output.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I'm also committing tests for and, or and xor in a
>>>>>>>>>>>>>>>>>>> minute. They are really simple and similar to the add and sub tests. Please
>>>>>>>>>>>>>>>>>>> review these :)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Mon, May 14, 2012 at 11:32 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Did you try adding the x86 and x64 targets with the avr
>>>>>>>>>>>>>>>>>>>> one? It's something related with an unsopported target.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Good question, I think there's no need to do reg+imm
>>>>>>>>>>>>>>>>>>>> for xor.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Btw remember to add the SF mailing list so we can have
>>>>>>>>>>>>>>>>>>>> a record ;)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2012/5/14 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Sorry, that is the llvm+clang trunk gives me 13
>>>>>>>>>>>>>>>>>>>>> unsupported tests, i.e. no failures versus the avr-llvm giving me 280
>>>>>>>>>>>>>>>>>>>>> unexpected failures.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Mon, May 14, 2012 at 9:08 PM, Nicklas Bo Jensen <
>>>>>>>>>>>>>>>>>>>>> nbj...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> BTW, the newest llvm and clang trunk only gives me 13
>>>>>>>>>>>>>>>>>>>>>> unexpected failures compared to the the newest trunk with avr-llvm where i
>>>>>>>>>>>>>>>>>>>>>> get 280 unexpected failures.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Considering the regression tests for xor, does it
>>>>>>>>>>>>>>>>>>>>>> make sense to test reg+imm, as the avr assembler does not have xor
>>>>>>>>>>>>>>>>>>>>>> for immediate?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Thu, May 10, 2012 at 9:12 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I don't think so, but I configured llvm to support
>>>>>>>>>>>>>>>>>>>>>>> both x86 and x64, so maybe that could help, in fact I can't build clang if
>>>>>>>>>>>>>>>>>>>>>>> I don't add support for x86.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 2012/5/10 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Target: x86_64-unknown-linux-gnu
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> But I only configured for avr... Did I do something
>>>>>>>>>>>>>>>>>>>>>>>> wrong?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Thu, May 10, 2012 at 5:32 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> This is what I'm getting:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Expected Passes : 9914
>>>>>>>>>>>>>>>>>>>>>>>>> Expected Failures : 66
>>>>>>>>>>>>>>>>>>>>>>>>> Unsupported Tests : 569
>>>>>>>>>>>>>>>>>>>>>>>>> Unexpected Failures: 11
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I've seen in that file you attached that you're
>>>>>>>>>>>>>>>>>>>>>>>>> getting errors because of the target triple, errors like:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> error: unable to create target: 'No available targets are compatible with this triple, see -version for the available targets.'
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> error auto-selecting target for module 'No available targets are compatible with this triple, see -version for the available targets
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> so I guess that's the reason, so what is your
>>>>>>>>>>>>>>>>>>>>>>>>> target triple? do clang -v to get it, mine is i386-pc-linux-gnu
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/10 Borja Ferrer <bor...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Interesting, I'll check it out tomorrow to see if
>>>>>>>>>>>>>>>>>>>>>>>>>> I can find some reason behind this, because we're getting very different
>>>>>>>>>>>>>>>>>>>>>>>>>> results here.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/9 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry for my slow response.Got i working again
>>>>>>>>>>>>>>>>>>>>>>>>>>> now, thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Building with optimization disabled and
>>>>>>>>>>>>>>>>>>>>>>>>>>> assertions turned on i get:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Avr llvm+clang:
>>>>>>>>>>>>>>>>>>>>>>>>>>> Expected Passes : 6978
>>>>>>>>>>>>>>>>>>>>>>>>>>> Expected Failures : 39
>>>>>>>>>>>>>>>>>>>>>>>>>>> Unsupported Tests : 3281
>>>>>>>>>>>>>>>>>>>>>>>>>>> Unexpected Failures: 279
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> In the 279 unexpected failures for example 143
>>>>>>>>>>>>>>>>>>>>>>>>>>> of them are test/CodeGen/Generic. I'm not really sure how these tests are
>>>>>>>>>>>>>>>>>>>>>>>>>>> supposed to work? None of them seems to be using FileCheck.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> However building for msp430 seems to be giving
>>>>>>>>>>>>>>>>>>>>>>>>>>> me similar results, indicating that it is not a avr-llvm specific problem.
>>>>>>>>>>>>>>>>>>>>>>>>>>> Please see the attached output "make check-all" from avr-llvm.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 4, 2012 at 11:30 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm asking because last week you said that you
>>>>>>>>>>>>>>>>>>>>>>>>>>>> were getting +200 fails, and since I'm getting 11 I wanted to know what's
>>>>>>>>>>>>>>>>>>>>>>>>>>>> going on.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> faluco is me btw, I updated a patch today
>>>>>>>>>>>>>>>>>>>>>>>>>>>> because I got a conflict when updating my clang repo. These variables are
>>>>>>>>>>>>>>>>>>>>>>>>>>>> defined in DiagnosticSemaKinds.td so check that you have them, they come
>>>>>>>>>>>>>>>>>>>>>>>>>>>> from the flash.diff patch.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The new tests should pass. I cannot check
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> other tests now, I'm having some issues after applying the newest patches
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that came in today by faluco:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /home/nicklas/install/avr-llvm/llvm/tools/clang/lib/Sema/SemaDecl.cpp:4374:38:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> error:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> no member named
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'err_flash_variable_requires_const' in namespace
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'clang::diag'
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Diag(NewVD->getLocation(),
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> diag::err_flash_variable_requires_const);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ~~~~~~^
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /home/nicklas/install/avr-llvm/llvm/tools/clang/lib/Sema/SemaDecl.cpp:4383:38:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> error:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> no member named
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'err_flash_pointer_requires_const' in namespace
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'clang::diag'
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Diag(NewVD->getLocation(),
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> diag::err_flash_pointer_requires_const);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ~~~~~~^
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /home/nicklas/install/avr-llvm/llvm/tools/clang/lib/Sema/SemaDecl.cpp:7208:25:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> error:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> no member named
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'err_flash_pointer_requires_const' in namespace
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'clang::diag'
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Diag(NameLoc,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> diag::err_flash_pointer_requires_const);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ~~~~~~^
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Have i done something wrong?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nicklas
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 4, 2012 at 8:50 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How many tests failures are you getting now?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm getting 11, 10 from clang due to address
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> space stuff (you'll need to patch clang to get those) and 1 from llvm.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Nicklas Bo Jensen <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ah, perfect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would actually guess that you need to run
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "make check-all" before being able to test new tests individually. Sorry :)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 4, 2012 at 8:17 PM, Borja Ferrer
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nevermind, got it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> One thing, i dont have llvm-lit in that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dir, am I supposed to build llvm with an addtional param or something in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> order to get it?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Nicklas Bo Jensen <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ok, I've committed now. To only run the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AVR specific tests run something like:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ./build/Debug+Asserts/bin/llvm-lit
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> llvm/test/CodeGen/AVR/
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 4, 2012 at 1:47 PM, Borja
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ferrer <bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Oh a small one I've just noticed, leave
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> only 1 newline between tests not 2.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ok they look great now, I don't have
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> any other objections. Please commit this test to SVN, post your SF username
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> here so that Eric or John can give you commit permissions. Once it gets
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> commited I'll check if I need to add any pattern specific tests to it,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> these tests are corner cases of some instructions.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Before commiting it, remove the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> testcases dir with all the files there, and create a new one called
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> test/CodeGen/AVR, and place your file there, just to keep the same
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> structure like in llvm's repo.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> About the rest of tests to do, from
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that list remove mul and division for now, mul isn't yet implemented and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> division can come later. Sub tests should be very similar to add, then add
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> binary ops (or, and, xor). Add calling convention tests (argument passing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> through regs and stack, return values for each value type, calls). Memory
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> operations, etc...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are quite a few tests to add, but
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for now do the sub and binary op tests and we'll discuss the others by then.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Nicklas Bo Jensen <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1) Sure
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2) Yes, I've followed the msp430
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> backend that does include it. I've removed it now.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3) Again, I've moved the CHECK lines,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> but it differs from backend to backend.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 4) Done
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 5) Done
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 6) Done
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I will continue working other tests,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which do we need? Something like(and please add/comment):
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -Sub
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -division(Only working for multiples
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of 2?)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -mult
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -Return argument(In a few variants)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -xor
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -increment
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -branching?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Any ideas?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nicklas
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, May 2, 2012 at 12:29 AM, Borja
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ferrer <bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Obviously in the last line I meant
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> adiw or subi/sbci pair, add for immediates doesn't exist for imms greater
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> than 63
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/2 Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> They look good, very nice :)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Some small details and nitpicks:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1) I think it's not necessary to add
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the reg_reg_imm variant because you covered it with the other two tests.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2) Do the tests work if you remove
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the target triple line? I've seen other backends don't include it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3) Move the CHECK lines after the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> function prototype like other backends do.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 4) In every CHECK line, can you
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> remove the tabs between the instr mnemonic and the first operand and add a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> single space? (I'm unsure about this because i dont know if CHECK eats
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> spaces). Also for the future, the llvm coding standards says to config your
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> editor to replace tabs with spaces, so it's a good moment time to do it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 5) Oh and the most important one,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> please add this in only one file, add.ll or something like that, so we can
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> keep this convention in the future, otherwise we'll end having too many
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> test files.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Something that should be covered is,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when doing 16 bit additions we can use adiw or add depending on the imm
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> value, can you cover this aswell?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/1 John Myers <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ato...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sun, Apr 29, 2012 at 10:46 AM,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nicklas Bo Jensen <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nbj...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I have successfully been able to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> compile your testcases (/avr-llvm/testcases/*.ll) to something looking like
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> valid avr assembler.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How should I test/simulate the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> assembler? I get errors when trying to simulate the generated assembler in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AVRStudio. Perhaps they use a different assembler?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> avr-llvm produces GNU assembler
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> syntax, which is different then the Atmel assembler syntax.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Eventually we could support
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> multiple asm syntax's like the X86 target does.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
|
|
From: Nicklas Bo J. <nbj...@gm...> - 2012-05-25 08:23:36
|
Is it more clear now? I think those tests have become too complicated and
we should delete them for now.
Also I'm seeing some wierd code for calling. I've attached a short piece of
code showing what I think could be a bug. After call foo, we are for
example doing "adiw r25:r24, 8", but the result from the call is stored in
these registers. That is not optimal. Also the addition with 5 never
happens. Is this because the function(calli64_stack) only returns void?
On Fri, May 25, 2012 at 12:06 AM, Nicklas Bo Jensen <nbj...@gm...>wrote:
> Ah i see. I had only implemented correct behaviour in return void, as we
> had not decided on a test style yet, meaning that those tests for returning
> the first argument were not testing anything. I have included a new version
> implementing the check at all cases.
>
> The regex is not needed in other tests, where we are not using CHECK-NEXT,
> as the comments are simply ignored here. When only using CHECK, there can
> be all kind of things between two CHECK's.
>
> On Thu, May 24, 2012 at 11:51 PM, Borja Ferrer <bor...@gm...>wrote:
>
>> Yes I understood it xD
>> What confuses me is that the first CHECK which checks the function name
>> label has a regex (the return_void: line), while the rest of tests don't
>> have it, meaning that the comment in the functionname label is not present
>> OR that when you only check for ret_void: (done in the rest of tests) and
>> then you use CHECK-NEXT it is still in the same line which doesn't make
>> sense to me at all, but who knows.
>>
>> I see that the BB#0 comment is always printed, so it has to be consumed
>> before you get into the real instructions.
>>
>> Basically if what i wrote is confusing, why is the first regexp needed
>> and not needed in the rest of cases?
>>
>>
>> 2012/5/24 Nicklas Bo Jensen <nbj...@gm...>
>>
>>> Sorry for my bad explanations :)
>>>
>>> For returning void and returning the first parameter directly the
>>> assembly looks like:
>>> return_void: # @return_void
>>> # BB#0:
>>> ret
>>>
>>> What I'm thinking is important to test in these cases is that there is
>>> no code between the label "return_void:" and "ret", only comments.
>>>
>>> Here CHECK-NEXT is a good choice, but the two comments makes it much
>>> harder to use CHECK-NEXT. Therefore the first regexp consumes the comment
>>> after the label and the second the comment on the next line, if not
>>> including the first regexp the second will match on the same line as the
>>> label.
>>>
>>> Does that make sense? Essentially it would be much easier to test if
>>> FileCheck had the option for ignoring comments.
>>>
>>>
>>>
>>> On Thu, May 24, 2012 at 11:03 PM, Borja Ferrer <bor...@gm...>wrote:
>>>
>>>> I'm a bit confused now, why is this comment only appearing in this test
>>>> then? I mean, for the rest of tests you didn't need to add that regex.
>>>>
>>>>
>>>> 2012/5/24 Nicklas Bo Jensen <nbj...@gm...>
>>>>
>>>>> The asm looks something like:
>>>>> return_void: # @return_void
>>>>> # BB#0:
>>>>> ret
>>>>>
>>>>> So the two regex's handle one comment each. It's far from perfect,
>>>>> should we just delete these testcases for now?
>>>>>
>>>>> On Thu, May 24, 2012 at 6:40 PM, Borja Ferrer <bor...@gm...>wrote:
>>>>>
>>>>>> I prefer the second, although it's a bit nasty it doesn't use an
>>>>>> external tool. For what is this regex used in CHECK:
>>>>>> return_void:{{[a-zA-Z0-9 #@]*}} ?
>>>>>>
>>>>>>
>>>>>> 2012/5/24 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>
>>>>>>> I agree. FileCheck should be able to ignore comments(at least as a
>>>>>>> parameter) like it ignores whitespaces.
>>>>>>>
>>>>>>> However I do have a few suggestions for how to do it, if you like
>>>>>>> one of them we can use it.
>>>>>>>
>>>>>>> 1. Previous suggestion with "hardcoded" comment.
>>>>>>> 2. Accept any comment after label:
>>>>>>> define void @return_void() {
>>>>>>> ; CHECK: return_void:{{[a-zA-Z0-9 #@]*}}
>>>>>>> ; CHECK-NEXT: #{{[a-zA-Z0-9 #@]*}}
>>>>>>> ; CHECK-NEXT: ret
>>>>>>> ret void
>>>>>>> }
>>>>>>>
>>>>>>> 3. Strip the assembler for comments and blank lines(here using sed)
>>>>>>> before checking.
>>>>>>> ; RUN: llc < %s -march=avr | sed "s/#.*//" | sed "/^$/d" | FileCheck
>>>>>>> %s
>>>>>>>
>>>>>>> define void @return_void() {
>>>>>>> ; CHECK: return_void:
>>>>>>> ; CHECK-NEXT: ret
>>>>>>> ret void
>>>>>>> }
>>>>>>>
>>>>>>> 2. is a bit complex and if we later choose to not print comments
>>>>>>> before blocks the test will fail.
>>>>>>> 3. is simpler, but requires a third party tool.
>>>>>>>
>>>>>>> What do you think Borja? I haven't found another backend dealing
>>>>>>> with this issue.
>>>>>>>
>>>>>>>
>>>>>>> On Thu, May 24, 2012 at 12:33 PM, Borja Ferrer <
>>>>>>> bor...@gm...> wrote:
>>>>>>>
>>>>>>>> I like it but checking for BB#0 is a bit nasty because it's a
>>>>>>>> comment and not an instruction, also that could change in the future
>>>>>>>> breaking the test.
>>>>>>>>
>>>>>>>> I've checked the other backends and we're testing things further
>>>>>>>> than what others do so I think there's no need for more tests there.
>>>>>>>>
>>>>>>>>
>>>>>>>> 2012/5/24 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>
>>>>>>>>> One idea could be to use CHECK-NEXT that checks if the string is
>>>>>>>>> on a consecutive line, then we could do something like:
>>>>>>>>>
>>>>>>>>> define void @return_void() {
>>>>>>>>> ; CHECK: return_void:
>>>>>>>>> ; CHECK-NEXT: # BB#0:
>>>>>>>>> ; CHECK-NEXT: ret
>>>>>>>>> ret void
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> The solution with the comment is not the best. What do you think?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, May 24, 2012 at 1:48 AM, Borja Ferrer <
>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>
>>>>>>>>>> Maybe you could check using CHECKNOT or whatever to make sure
>>>>>>>>>> that no moves are emitted, that would cover it.
>>>>>>>>>>
>>>>>>>>>> I'll check what other backends do regarding these tests and see
>>>>>>>>>> if I can come up with further things.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2012/5/23 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>
>>>>>>>>>>> Are the following tests obsolete, as there in my opinion is no
>>>>>>>>>>> really good way to test them using FileCheck(with my current return
>>>>>>>>>>> tests(included) we could return the wrong argument)?
>>>>>>>>>>>
>>>>>>>>>>> - Returning void.
>>>>>>>>>>> - Returning the first parameter, which is already in the
>>>>>>>>>>> correct place.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Do we need additional tests for returning, besides
>>>>>>>>>>> returning immediate and argument, like returning a value from register or
>>>>>>>>>>> is it already covered in returning a argument?
>>>>>>>>>>>
>>>>>>>>>>> On Wed, May 23, 2012 at 12:51 AM, Borja Ferrer <
>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Yes, that's something handled by llvm, not the backend so we
>>>>>>>>>>>> can't do too much there, although it would be a nice optimization to do.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2012/5/23 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks for the explanation. It's clear :)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Out of curiosity, why are the pushes and pops in the example
>>>>>>>>>>>>> below? movw leaves r17:r14 unchanged. Do we simply push and pop all
>>>>>>>>>>>>> registers to be on the safe side and limited static analysis?
>>>>>>>>>>>>>
>>>>>>>>>>>>> llvm:
>>>>>>>>>>>>> define i32 @return32_arg2(i32 %x, i32 %y, i32 %z) {
>>>>>>>>>>>>> ret i32 %z
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> asm:
>>>>>>>>>>>>> return32_arg2:
>>>>>>>>>>>>> push r14
>>>>>>>>>>>>> push r15
>>>>>>>>>>>>> push r16
>>>>>>>>>>>>> push r17
>>>>>>>>>>>>> movw r23:r22, r15:r14
>>>>>>>>>>>>> movw r25:r24, r17:r16
>>>>>>>>>>>>> pop r17
>>>>>>>>>>>>> pop r16
>>>>>>>>>>>>> pop r15
>>>>>>>>>>>>> pop r14
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, May 22, 2012 at 11:32 PM, Borja Ferrer <
>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Here you have a link that explains how registers are used:
>>>>>>>>>>>>>> www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_reg_usage
>>>>>>>>>>>>>> Testing a calling convention without knowing how it actually
>>>>>>>>>>>>>> works is going to be an insane task to do xD
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> About your question, when you read that link all will become
>>>>>>>>>>>>>> clear but basically here is what's going on. Arguments are passed from r25
>>>>>>>>>>>>>> down to r8, since in this case three 64bit args can't fit in those
>>>>>>>>>>>>>> registers the last argument is passed through the stack, so you get:
>>>>>>>>>>>>>> arg1 is in: r25-r18
>>>>>>>>>>>>>> arg2 is in: r17-r10
>>>>>>>>>>>>>> arg3 obviously doesn't fit in 2 register so it's all passed
>>>>>>>>>>>>>> through the stack, thats why you get those loads. Notice that the lowest
>>>>>>>>>>>>>> part of the argument is in Y+5 because in +4 and +3 is r29:r28 you just
>>>>>>>>>>>>>> pushed and in +2 +1 is the the return address that was pushed into the
>>>>>>>>>>>>>> stack after the call was performed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Another thing, you should add checks on the pushes and pops
>>>>>>>>>>>>>> for the callee saved registers so we're sure that they're being saved.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2012/5/22 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Perfect :)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm moving on to calling convention and have started with
>>>>>>>>>>>>>>> return values. However I'm a bit unsure what the calling convention
>>>>>>>>>>>>>>> actually is. For example with my last test, called "return64_arg2" in the
>>>>>>>>>>>>>>> attached .ll file and the generated assembly in the .s file, is the correct
>>>>>>>>>>>>>>> thing happening and how it should be tested? Couldn't we have passed the
>>>>>>>>>>>>>>> arguments in the normal registers? I.e. r25:r2.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If the arguments don't fit in the registers, do we always
>>>>>>>>>>>>>>> store the result in the same place in ram?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, May 21, 2012 at 11:38 PM, Borja Ferrer <
>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nice, so now you have the same test failures as me, they
>>>>>>>>>>>>>>>> are caused because we're using custom address space stuff in clang, dont
>>>>>>>>>>>>>>>> worry about those. Basically they fail because these tests are writing into
>>>>>>>>>>>>>>>> address space 1 which is flash data and that is forbidden in our target
>>>>>>>>>>>>>>>> (remember flash memory is readonly).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The test cases you just commited look great :) To which
>>>>>>>>>>>>>>>> ones are you going to move on next?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes, that code looks correct, where is the problem?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2012/5/21 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Is the following generated code correct:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> LLVM:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> define i8 @return8_arg(i8 %x) {
>>>>>>>>>>>>>>>>> ret i8 %x
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Generated:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> return8_arg:
>>>>>>>>>>>>>>>>> ret
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Something similar in .c compiling with avr-gcc gives a few
>>>>>>>>>>>>>>>>> pushes, loads and pops.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Mon, May 21, 2012 at 10:48 PM, Nicklas Bo Jensen <
>>>>>>>>>>>>>>>>> nbj...@gm...> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> When adding those targets I only have 10 unexpected
>>>>>>>>>>>>>>>>>> failures:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Clang :: CodeGen/address-space-compound-literal.c
>>>>>>>>>>>>>>>>>> Clang :: CodeGen/address-space-field1.c
>>>>>>>>>>>>>>>>>> Clang :: CodeGen/address-space.c
>>>>>>>>>>>>>>>>>> Clang :: CodeGenCXX/mangle-address-space.cpp
>>>>>>>>>>>>>>>>>> Clang :: PCH/types.c
>>>>>>>>>>>>>>>>>> Clang :: Sema/address_spaces.c
>>>>>>>>>>>>>>>>>> Clang :: SemaCXX/address-space-conversion.cpp
>>>>>>>>>>>>>>>>>> Clang :: SemaCXX/address-space-newdelete.cpp
>>>>>>>>>>>>>>>>>> Clang :: SemaCXX/address-space-references.cpp
>>>>>>>>>>>>>>>>>> Clang :: SemaTemplate/address-spaces.cpp
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I will try to run each test separately and try to figure
>>>>>>>>>>>>>>>>>> out why they are failing. I have also attached the test output.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I'm also committing tests for and, or and xor in a
>>>>>>>>>>>>>>>>>> minute. They are really simple and similar to the add and sub tests. Please
>>>>>>>>>>>>>>>>>> review these :)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Mon, May 14, 2012 at 11:32 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Did you try adding the x86 and x64 targets with the avr
>>>>>>>>>>>>>>>>>>> one? It's something related with an unsopported target.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Good question, I think there's no need to do reg+imm for
>>>>>>>>>>>>>>>>>>> xor.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Btw remember to add the SF mailing list so we can have a
>>>>>>>>>>>>>>>>>>> record ;)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2012/5/14 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Sorry, that is the llvm+clang trunk gives me 13
>>>>>>>>>>>>>>>>>>>> unsupported tests, i.e. no failures versus the avr-llvm giving me 280
>>>>>>>>>>>>>>>>>>>> unexpected failures.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Mon, May 14, 2012 at 9:08 PM, Nicklas Bo Jensen <
>>>>>>>>>>>>>>>>>>>> nbj...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> BTW, the newest llvm and clang trunk only gives me 13
>>>>>>>>>>>>>>>>>>>>> unexpected failures compared to the the newest trunk with avr-llvm where i
>>>>>>>>>>>>>>>>>>>>> get 280 unexpected failures.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Considering the regression tests for xor, does it make
>>>>>>>>>>>>>>>>>>>>> sense to test reg+imm, as the avr assembler does not have xor for immediate?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Thu, May 10, 2012 at 9:12 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I don't think so, but I configured llvm to support
>>>>>>>>>>>>>>>>>>>>>> both x86 and x64, so maybe that could help, in fact I can't build clang if
>>>>>>>>>>>>>>>>>>>>>> I don't add support for x86.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 2012/5/10 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Target: x86_64-unknown-linux-gnu
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> But I only configured for avr... Did I do something
>>>>>>>>>>>>>>>>>>>>>>> wrong?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Thu, May 10, 2012 at 5:32 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> This is what I'm getting:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Expected Passes : 9914
>>>>>>>>>>>>>>>>>>>>>>>> Expected Failures : 66
>>>>>>>>>>>>>>>>>>>>>>>> Unsupported Tests : 569
>>>>>>>>>>>>>>>>>>>>>>>> Unexpected Failures: 11
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I've seen in that file you attached that you're
>>>>>>>>>>>>>>>>>>>>>>>> getting errors because of the target triple, errors like:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> error: unable to create target: 'No available targets are compatible with this triple, see -version for the available targets.'
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> error auto-selecting target for module 'No available targets are compatible with this triple, see -version for the available targets
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> so I guess that's the reason, so what is your
>>>>>>>>>>>>>>>>>>>>>>>> target triple? do clang -v to get it, mine is i386-pc-linux-gnu
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/10 Borja Ferrer <bor...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Interesting, I'll check it out tomorrow to see if
>>>>>>>>>>>>>>>>>>>>>>>>> I can find some reason behind this, because we're getting very different
>>>>>>>>>>>>>>>>>>>>>>>>> results here.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/9 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry for my slow response.Got i working again
>>>>>>>>>>>>>>>>>>>>>>>>>> now, thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Building with optimization disabled and
>>>>>>>>>>>>>>>>>>>>>>>>>> assertions turned on i get:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Avr llvm+clang:
>>>>>>>>>>>>>>>>>>>>>>>>>> Expected Passes : 6978
>>>>>>>>>>>>>>>>>>>>>>>>>> Expected Failures : 39
>>>>>>>>>>>>>>>>>>>>>>>>>> Unsupported Tests : 3281
>>>>>>>>>>>>>>>>>>>>>>>>>> Unexpected Failures: 279
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> In the 279 unexpected failures for example 143 of
>>>>>>>>>>>>>>>>>>>>>>>>>> them are test/CodeGen/Generic. I'm not really sure how these tests are
>>>>>>>>>>>>>>>>>>>>>>>>>> supposed to work? None of them seems to be using FileCheck.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> However building for msp430 seems to be giving me
>>>>>>>>>>>>>>>>>>>>>>>>>> similar results, indicating that it is not a avr-llvm specific problem.
>>>>>>>>>>>>>>>>>>>>>>>>>> Please see the attached output "make check-all" from avr-llvm.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 4, 2012 at 11:30 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm asking because last week you said that you
>>>>>>>>>>>>>>>>>>>>>>>>>>> were getting +200 fails, and since I'm getting 11 I wanted to know what's
>>>>>>>>>>>>>>>>>>>>>>>>>>> going on.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> faluco is me btw, I updated a patch today
>>>>>>>>>>>>>>>>>>>>>>>>>>> because I got a conflict when updating my clang repo. These variables are
>>>>>>>>>>>>>>>>>>>>>>>>>>> defined in DiagnosticSemaKinds.td so check that you have them, they come
>>>>>>>>>>>>>>>>>>>>>>>>>>> from the flash.diff patch.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> The new tests should pass. I cannot check other
>>>>>>>>>>>>>>>>>>>>>>>>>>>> tests now, I'm having some issues after applying the newest patches that
>>>>>>>>>>>>>>>>>>>>>>>>>>>> came in today by faluco:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> /home/nicklas/install/avr-llvm/llvm/tools/clang/lib/Sema/SemaDecl.cpp:4374:38:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> error:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> no member named
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'err_flash_variable_requires_const' in namespace
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'clang::diag'
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Diag(NewVD->getLocation(),
>>>>>>>>>>>>>>>>>>>>>>>>>>>> diag::err_flash_variable_requires_const);
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ~~~~~~^
>>>>>>>>>>>>>>>>>>>>>>>>>>>> /home/nicklas/install/avr-llvm/llvm/tools/clang/lib/Sema/SemaDecl.cpp:4383:38:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> error:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> no member named
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'err_flash_pointer_requires_const' in namespace
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'clang::diag'
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Diag(NewVD->getLocation(),
>>>>>>>>>>>>>>>>>>>>>>>>>>>> diag::err_flash_pointer_requires_const);
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ~~~~~~^
>>>>>>>>>>>>>>>>>>>>>>>>>>>> /home/nicklas/install/avr-llvm/llvm/tools/clang/lib/Sema/SemaDecl.cpp:7208:25:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> error:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> no member named
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'err_flash_pointer_requires_const' in namespace
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'clang::diag'
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Diag(NameLoc,
>>>>>>>>>>>>>>>>>>>>>>>>>>>> diag::err_flash_pointer_requires_const);
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ~~~~~~^
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Have i done something wrong?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nicklas
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 4, 2012 at 8:50 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How many tests failures are you getting now?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm getting 11, 10 from clang due to address
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> space stuff (you'll need to patch clang to get those) and 1 from llvm.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Nicklas Bo Jensen <nbj...@gm...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ah, perfect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would actually guess that you need to run
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "make check-all" before being able to test new tests individually. Sorry :)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 4, 2012 at 8:17 PM, Borja Ferrer
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nevermind, got it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Borja Ferrer <bor...@gm...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> One thing, i dont have llvm-lit in that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dir, am I supposed to build llvm with an addtional param or something in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> order to get it?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Nicklas Bo Jensen <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ok, I've committed now. To only run the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AVR specific tests run something like:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ./build/Debug+Asserts/bin/llvm-lit
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> llvm/test/CodeGen/AVR/
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 4, 2012 at 1:47 PM, Borja
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ferrer <bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Oh a small one I've just noticed, leave
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> only 1 newline between tests not 2.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ok they look great now, I don't have any
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> other objections. Please commit this test to SVN, post your SF username
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> here so that Eric or John can give you commit permissions. Once it gets
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> commited I'll check if I need to add any pattern specific tests to it,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> these tests are corner cases of some instructions.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Before commiting it, remove the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> testcases dir with all the files there, and create a new one called
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> test/CodeGen/AVR, and place your file there, just to keep the same
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> structure like in llvm's repo.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> About the rest of tests to do, from that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> list remove mul and division for now, mul isn't yet implemented and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> division can come later. Sub tests should be very similar to add, then add
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> binary ops (or, and, xor). Add calling convention tests (argument passing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> through regs and stack, return values for each value type, calls). Memory
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> operations, etc...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are quite a few tests to add, but
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for now do the sub and binary op tests and we'll discuss the others by then.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Nicklas Bo Jensen <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1) Sure
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2) Yes, I've followed the msp430
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> backend that does include it. I've removed it now.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3) Again, I've moved the CHECK lines,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> but it differs from backend to backend.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 4) Done
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 5) Done
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 6) Done
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I will continue working other tests,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which do we need? Something like(and please add/comment):
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -Sub
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -division(Only working for multiples of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2?)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -mult
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -Return argument(In a few variants)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -xor
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -increment
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -branching?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Any ideas?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nicklas
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, May 2, 2012 at 12:29 AM, Borja
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ferrer <bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Obviously in the last line I meant
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> adiw or subi/sbci pair, add for immediates doesn't exist for imms greater
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> than 63
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/2 Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> They look good, very nice :)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Some small details and nitpicks:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1) I think it's not necessary to add
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the reg_reg_imm variant because you covered it with the other two tests.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2) Do the tests work if you remove
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the target triple line? I've seen other backends don't include it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3) Move the CHECK lines after the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> function prototype like other backends do.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 4) In every CHECK line, can you
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> remove the tabs between the instr mnemonic and the first operand and add a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> single space? (I'm unsure about this because i dont know if CHECK eats
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> spaces). Also for the future, the llvm coding standards says to config your
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> editor to replace tabs with spaces, so it's a good moment time to do it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 5) Oh and the most important one,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> please add this in only one file, add.ll or something like that, so we can
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> keep this convention in the future, otherwise we'll end having too many
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> test files.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Something that should be covered is,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when doing 16 bit additions we can use adiw or add depending on the imm
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> value, can you cover this aswell?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/1 John Myers <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ato...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sun, Apr 29, 2012 at 10:46 AM,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nicklas Bo Jensen <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nbj...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I have successfully been able to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> compile your testcases (/avr-llvm/testcases/*.ll) to something looking like
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> valid avr assembler.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How should I test/simulate the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> assembler? I get errors when trying to simulate the generated assembler in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AVRStudio. Perhaps they use a different assembler?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> avr-llvm produces GNU assembler
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> syntax, which is different then the Atmel assembler syntax.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Eventually we could support multiple
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> asm syntax's like the X86 target does.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
|
|
From: Borja F. <bor...@gm...> - 2012-05-24 21:51:17
|
Yes I understood it xD
What confuses me is that the first CHECK which checks the function name
label has a regex (the return_void: line), while the rest of tests don't
have it, meaning that the comment in the functionname label is not present
OR that when you only check for ret_void: (done in the rest of tests) and
then you use CHECK-NEXT it is still in the same line which doesn't make
sense to me at all, but who knows.
I see that the BB#0 comment is always printed, so it has to be consumed
before you get into the real instructions.
Basically if what i wrote is confusing, why is the first regexp needed and
not needed in the rest of cases?
2012/5/24 Nicklas Bo Jensen <nbj...@gm...>
> Sorry for my bad explanations :)
>
> For returning void and returning the first parameter directly the assembly
> looks like:
> return_void: # @return_void
> # BB#0:
> ret
>
> What I'm thinking is important to test in these cases is that there is no
> code between the label "return_void:" and "ret", only comments.
>
> Here CHECK-NEXT is a good choice, but the two comments makes it much
> harder to use CHECK-NEXT. Therefore the first regexp consumes the comment
> after the label and the second the comment on the next line, if not
> including the first regexp the second will match on the same line as the
> label.
>
> Does that make sense? Essentially it would be much easier to test if
> FileCheck had the option for ignoring comments.
>
>
>
> On Thu, May 24, 2012 at 11:03 PM, Borja Ferrer <bor...@gm...>wrote:
>
>> I'm a bit confused now, why is this comment only appearing in this test
>> then? I mean, for the rest of tests you didn't need to add that regex.
>>
>>
>> 2012/5/24 Nicklas Bo Jensen <nbj...@gm...>
>>
>>> The asm looks something like:
>>> return_void: # @return_void
>>> # BB#0:
>>> ret
>>>
>>> So the two regex's handle one comment each. It's far from perfect,
>>> should we just delete these testcases for now?
>>>
>>> On Thu, May 24, 2012 at 6:40 PM, Borja Ferrer <bor...@gm...>wrote:
>>>
>>>> I prefer the second, although it's a bit nasty it doesn't use an
>>>> external tool. For what is this regex used in CHECK:
>>>> return_void:{{[a-zA-Z0-9 #@]*}} ?
>>>>
>>>>
>>>> 2012/5/24 Nicklas Bo Jensen <nbj...@gm...>
>>>>
>>>>> I agree. FileCheck should be able to ignore comments(at least as a
>>>>> parameter) like it ignores whitespaces.
>>>>>
>>>>> However I do have a few suggestions for how to do it, if you like one
>>>>> of them we can use it.
>>>>>
>>>>> 1. Previous suggestion with "hardcoded" comment.
>>>>> 2. Accept any comment after label:
>>>>> define void @return_void() {
>>>>> ; CHECK: return_void:{{[a-zA-Z0-9 #@]*}}
>>>>> ; CHECK-NEXT: #{{[a-zA-Z0-9 #@]*}}
>>>>> ; CHECK-NEXT: ret
>>>>> ret void
>>>>> }
>>>>>
>>>>> 3. Strip the assembler for comments and blank lines(here using sed)
>>>>> before checking.
>>>>> ; RUN: llc < %s -march=avr | sed "s/#.*//" | sed "/^$/d" | FileCheck %s
>>>>>
>>>>> define void @return_void() {
>>>>> ; CHECK: return_void:
>>>>> ; CHECK-NEXT: ret
>>>>> ret void
>>>>> }
>>>>>
>>>>> 2. is a bit complex and if we later choose to not print comments
>>>>> before blocks the test will fail.
>>>>> 3. is simpler, but requires a third party tool.
>>>>>
>>>>> What do you think Borja? I haven't found another backend dealing with
>>>>> this issue.
>>>>>
>>>>>
>>>>> On Thu, May 24, 2012 at 12:33 PM, Borja Ferrer <bor...@gm...>wrote:
>>>>>
>>>>>> I like it but checking for BB#0 is a bit nasty because it's a comment
>>>>>> and not an instruction, also that could change in the future breaking the
>>>>>> test.
>>>>>>
>>>>>> I've checked the other backends and we're testing things further than
>>>>>> what others do so I think there's no need for more tests there.
>>>>>>
>>>>>>
>>>>>> 2012/5/24 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>
>>>>>>> One idea could be to use CHECK-NEXT that checks if the string is on
>>>>>>> a consecutive line, then we could do something like:
>>>>>>>
>>>>>>> define void @return_void() {
>>>>>>> ; CHECK: return_void:
>>>>>>> ; CHECK-NEXT: # BB#0:
>>>>>>> ; CHECK-NEXT: ret
>>>>>>> ret void
>>>>>>> }
>>>>>>>
>>>>>>> The solution with the comment is not the best. What do you think?
>>>>>>>
>>>>>>>
>>>>>>> On Thu, May 24, 2012 at 1:48 AM, Borja Ferrer <bor...@gm...
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> Maybe you could check using CHECKNOT or whatever to make sure that
>>>>>>>> no moves are emitted, that would cover it.
>>>>>>>>
>>>>>>>> I'll check what other backends do regarding these tests and see if
>>>>>>>> I can come up with further things.
>>>>>>>>
>>>>>>>>
>>>>>>>> 2012/5/23 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>
>>>>>>>>> Are the following tests obsolete, as there in my opinion is no
>>>>>>>>> really good way to test them using FileCheck(with my current return
>>>>>>>>> tests(included) we could return the wrong argument)?
>>>>>>>>>
>>>>>>>>> - Returning void.
>>>>>>>>> - Returning the first parameter, which is already in the
>>>>>>>>> correct place.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Do we need additional tests for returning, besides
>>>>>>>>> returning immediate and argument, like returning a value from register or
>>>>>>>>> is it already covered in returning a argument?
>>>>>>>>>
>>>>>>>>> On Wed, May 23, 2012 at 12:51 AM, Borja Ferrer <
>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>
>>>>>>>>>> Yes, that's something handled by llvm, not the backend so we
>>>>>>>>>> can't do too much there, although it would be a nice optimization to do.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2012/5/23 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>
>>>>>>>>>>> Thanks for the explanation. It's clear :)
>>>>>>>>>>>
>>>>>>>>>>> Out of curiosity, why are the pushes and pops in the example
>>>>>>>>>>> below? movw leaves r17:r14 unchanged. Do we simply push and pop all
>>>>>>>>>>> registers to be on the safe side and limited static analysis?
>>>>>>>>>>>
>>>>>>>>>>> llvm:
>>>>>>>>>>> define i32 @return32_arg2(i32 %x, i32 %y, i32 %z) {
>>>>>>>>>>> ret i32 %z
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> asm:
>>>>>>>>>>> return32_arg2:
>>>>>>>>>>> push r14
>>>>>>>>>>> push r15
>>>>>>>>>>> push r16
>>>>>>>>>>> push r17
>>>>>>>>>>> movw r23:r22, r15:r14
>>>>>>>>>>> movw r25:r24, r17:r16
>>>>>>>>>>> pop r17
>>>>>>>>>>> pop r16
>>>>>>>>>>> pop r15
>>>>>>>>>>> pop r14
>>>>>>>>>>>
>>>>>>>>>>> On Tue, May 22, 2012 at 11:32 PM, Borja Ferrer <
>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Here you have a link that explains how registers are used:
>>>>>>>>>>>> www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_reg_usage
>>>>>>>>>>>> Testing a calling convention without knowing how it actually
>>>>>>>>>>>> works is going to be an insane task to do xD
>>>>>>>>>>>>
>>>>>>>>>>>> About your question, when you read that link all will become
>>>>>>>>>>>> clear but basically here is what's going on. Arguments are passed from r25
>>>>>>>>>>>> down to r8, since in this case three 64bit args can't fit in those
>>>>>>>>>>>> registers the last argument is passed through the stack, so you get:
>>>>>>>>>>>> arg1 is in: r25-r18
>>>>>>>>>>>> arg2 is in: r17-r10
>>>>>>>>>>>> arg3 obviously doesn't fit in 2 register so it's all passed
>>>>>>>>>>>> through the stack, thats why you get those loads. Notice that the lowest
>>>>>>>>>>>> part of the argument is in Y+5 because in +4 and +3 is r29:r28 you just
>>>>>>>>>>>> pushed and in +2 +1 is the the return address that was pushed into the
>>>>>>>>>>>> stack after the call was performed.
>>>>>>>>>>>>
>>>>>>>>>>>> Another thing, you should add checks on the pushes and pops for
>>>>>>>>>>>> the callee saved registers so we're sure that they're being saved.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2012/5/22 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>
>>>>>>>>>>>>> Perfect :)
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm moving on to calling convention and have started with
>>>>>>>>>>>>> return values. However I'm a bit unsure what the calling convention
>>>>>>>>>>>>> actually is. For example with my last test, called "return64_arg2" in the
>>>>>>>>>>>>> attached .ll file and the generated assembly in the .s file, is the correct
>>>>>>>>>>>>> thing happening and how it should be tested? Couldn't we have passed the
>>>>>>>>>>>>> arguments in the normal registers? I.e. r25:r2.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If the arguments don't fit in the registers, do we always
>>>>>>>>>>>>> store the result in the same place in ram?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, May 21, 2012 at 11:38 PM, Borja Ferrer <
>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nice, so now you have the same test failures as me, they are
>>>>>>>>>>>>>> caused because we're using custom address space stuff in clang, dont worry
>>>>>>>>>>>>>> about those. Basically they fail because these tests are writing into
>>>>>>>>>>>>>> address space 1 which is flash data and that is forbidden in our target
>>>>>>>>>>>>>> (remember flash memory is readonly).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The test cases you just commited look great :) To which ones
>>>>>>>>>>>>>> are you going to move on next?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes, that code looks correct, where is the problem?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2012/5/21 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Is the following generated code correct:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> LLVM:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> define i8 @return8_arg(i8 %x) {
>>>>>>>>>>>>>>> ret i8 %x
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Generated:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> return8_arg:
>>>>>>>>>>>>>>> ret
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Something similar in .c compiling with avr-gcc gives a few
>>>>>>>>>>>>>>> pushes, loads and pops.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, May 21, 2012 at 10:48 PM, Nicklas Bo Jensen <
>>>>>>>>>>>>>>> nbj...@gm...> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> When adding those targets I only have 10 unexpected
>>>>>>>>>>>>>>>> failures:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Clang :: CodeGen/address-space-compound-literal.c
>>>>>>>>>>>>>>>> Clang :: CodeGen/address-space-field1.c
>>>>>>>>>>>>>>>> Clang :: CodeGen/address-space.c
>>>>>>>>>>>>>>>> Clang :: CodeGenCXX/mangle-address-space.cpp
>>>>>>>>>>>>>>>> Clang :: PCH/types.c
>>>>>>>>>>>>>>>> Clang :: Sema/address_spaces.c
>>>>>>>>>>>>>>>> Clang :: SemaCXX/address-space-conversion.cpp
>>>>>>>>>>>>>>>> Clang :: SemaCXX/address-space-newdelete.cpp
>>>>>>>>>>>>>>>> Clang :: SemaCXX/address-space-references.cpp
>>>>>>>>>>>>>>>> Clang :: SemaTemplate/address-spaces.cpp
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I will try to run each test separately and try to figure
>>>>>>>>>>>>>>>> out why they are failing. I have also attached the test output.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm also committing tests for and, or and xor in a minute.
>>>>>>>>>>>>>>>> They are really simple and similar to the add and sub tests. Please review
>>>>>>>>>>>>>>>> these :)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Mon, May 14, 2012 at 11:32 PM, Borja Ferrer <
>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Did you try adding the x86 and x64 targets with the avr
>>>>>>>>>>>>>>>>> one? It's something related with an unsopported target.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Good question, I think there's no need to do reg+imm for
>>>>>>>>>>>>>>>>> xor.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Btw remember to add the SF mailing list so we can have a
>>>>>>>>>>>>>>>>> record ;)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2012/5/14 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Sorry, that is the llvm+clang trunk gives me 13
>>>>>>>>>>>>>>>>>> unsupported tests, i.e. no failures versus the avr-llvm giving me 280
>>>>>>>>>>>>>>>>>> unexpected failures.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Mon, May 14, 2012 at 9:08 PM, Nicklas Bo Jensen <
>>>>>>>>>>>>>>>>>> nbj...@gm...> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> BTW, the newest llvm and clang trunk only gives me 13
>>>>>>>>>>>>>>>>>>> unexpected failures compared to the the newest trunk with avr-llvm where i
>>>>>>>>>>>>>>>>>>> get 280 unexpected failures.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Considering the regression tests for xor, does it make
>>>>>>>>>>>>>>>>>>> sense to test reg+imm, as the avr assembler does not have xor for immediate?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Thu, May 10, 2012 at 9:12 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I don't think so, but I configured llvm to support both
>>>>>>>>>>>>>>>>>>>> x86 and x64, so maybe that could help, in fact I can't build clang if I
>>>>>>>>>>>>>>>>>>>> don't add support for x86.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2012/5/10 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Target: x86_64-unknown-linux-gnu
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> But I only configured for avr... Did I do something
>>>>>>>>>>>>>>>>>>>>> wrong?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Thu, May 10, 2012 at 5:32 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> This is what I'm getting:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Expected Passes : 9914
>>>>>>>>>>>>>>>>>>>>>> Expected Failures : 66
>>>>>>>>>>>>>>>>>>>>>> Unsupported Tests : 569
>>>>>>>>>>>>>>>>>>>>>> Unexpected Failures: 11
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I've seen in that file you attached that you're
>>>>>>>>>>>>>>>>>>>>>> getting errors because of the target triple, errors like:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> error: unable to create target: 'No available targets are compatible with this triple, see -version for the available targets.'
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> error auto-selecting target for module 'No available targets are compatible with this triple, see -version for the available targets
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> so I guess that's the reason, so what is your target
>>>>>>>>>>>>>>>>>>>>>> triple? do clang -v to get it, mine is i386-pc-linux-gnu
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 2012/5/10 Borja Ferrer <bor...@gm...>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Interesting, I'll check it out tomorrow to see if I
>>>>>>>>>>>>>>>>>>>>>>> can find some reason behind this, because we're getting very different
>>>>>>>>>>>>>>>>>>>>>>> results here.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 2012/5/9 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Sorry for my slow response.Got i working again now,
>>>>>>>>>>>>>>>>>>>>>>>> thanks.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Building with optimization disabled and assertions
>>>>>>>>>>>>>>>>>>>>>>>> turned on i get:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Avr llvm+clang:
>>>>>>>>>>>>>>>>>>>>>>>> Expected Passes : 6978
>>>>>>>>>>>>>>>>>>>>>>>> Expected Failures : 39
>>>>>>>>>>>>>>>>>>>>>>>> Unsupported Tests : 3281
>>>>>>>>>>>>>>>>>>>>>>>> Unexpected Failures: 279
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> In the 279 unexpected failures for example 143 of
>>>>>>>>>>>>>>>>>>>>>>>> them are test/CodeGen/Generic. I'm not really sure how these tests are
>>>>>>>>>>>>>>>>>>>>>>>> supposed to work? None of them seems to be using FileCheck.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> However building for msp430 seems to be giving me
>>>>>>>>>>>>>>>>>>>>>>>> similar results, indicating that it is not a avr-llvm specific problem.
>>>>>>>>>>>>>>>>>>>>>>>> Please see the attached output "make check-all" from avr-llvm.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 4, 2012 at 11:30 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I'm asking because last week you said that you
>>>>>>>>>>>>>>>>>>>>>>>>> were getting +200 fails, and since I'm getting 11 I wanted to know what's
>>>>>>>>>>>>>>>>>>>>>>>>> going on.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> faluco is me btw, I updated a patch today because
>>>>>>>>>>>>>>>>>>>>>>>>> I got a conflict when updating my clang repo. These variables are defined
>>>>>>>>>>>>>>>>>>>>>>>>> in DiagnosticSemaKinds.td so check that you have them, they come from the
>>>>>>>>>>>>>>>>>>>>>>>>> flash.diff patch.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> The new tests should pass. I cannot check other
>>>>>>>>>>>>>>>>>>>>>>>>>> tests now, I'm having some issues after applying the newest patches that
>>>>>>>>>>>>>>>>>>>>>>>>>> came in today by faluco:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> /home/nicklas/install/avr-llvm/llvm/tools/clang/lib/Sema/SemaDecl.cpp:4374:38:
>>>>>>>>>>>>>>>>>>>>>>>>>> error:
>>>>>>>>>>>>>>>>>>>>>>>>>> no member named
>>>>>>>>>>>>>>>>>>>>>>>>>> 'err_flash_variable_requires_const' in namespace
>>>>>>>>>>>>>>>>>>>>>>>>>> 'clang::diag'
>>>>>>>>>>>>>>>>>>>>>>>>>> Diag(NewVD->getLocation(),
>>>>>>>>>>>>>>>>>>>>>>>>>> diag::err_flash_variable_requires_const);
>>>>>>>>>>>>>>>>>>>>>>>>>> ~~~~~~^
>>>>>>>>>>>>>>>>>>>>>>>>>> /home/nicklas/install/avr-llvm/llvm/tools/clang/lib/Sema/SemaDecl.cpp:4383:38:
>>>>>>>>>>>>>>>>>>>>>>>>>> error:
>>>>>>>>>>>>>>>>>>>>>>>>>> no member named
>>>>>>>>>>>>>>>>>>>>>>>>>> 'err_flash_pointer_requires_const' in namespace
>>>>>>>>>>>>>>>>>>>>>>>>>> 'clang::diag'
>>>>>>>>>>>>>>>>>>>>>>>>>> Diag(NewVD->getLocation(),
>>>>>>>>>>>>>>>>>>>>>>>>>> diag::err_flash_pointer_requires_const);
>>>>>>>>>>>>>>>>>>>>>>>>>> ~~~~~~^
>>>>>>>>>>>>>>>>>>>>>>>>>> /home/nicklas/install/avr-llvm/llvm/tools/clang/lib/Sema/SemaDecl.cpp:7208:25:
>>>>>>>>>>>>>>>>>>>>>>>>>> error:
>>>>>>>>>>>>>>>>>>>>>>>>>> no member named
>>>>>>>>>>>>>>>>>>>>>>>>>> 'err_flash_pointer_requires_const' in namespace
>>>>>>>>>>>>>>>>>>>>>>>>>> 'clang::diag'
>>>>>>>>>>>>>>>>>>>>>>>>>> Diag(NameLoc,
>>>>>>>>>>>>>>>>>>>>>>>>>> diag::err_flash_pointer_requires_const);
>>>>>>>>>>>>>>>>>>>>>>>>>> ~~~~~~^
>>>>>>>>>>>>>>>>>>>>>>>>>> Have i done something wrong?
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>> Nicklas
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 4, 2012 at 8:50 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> How many tests failures are you getting now?
>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm getting 11, 10 from clang due to address
>>>>>>>>>>>>>>>>>>>>>>>>>>> space stuff (you'll need to patch clang to get those) and 1 from llvm.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ah, perfect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would actually guess that you need to run
>>>>>>>>>>>>>>>>>>>>>>>>>>>> "make check-all" before being able to test new tests individually. Sorry :)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 4, 2012 at 8:17 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nevermind, got it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Borja Ferrer <bor...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> One thing, i dont have llvm-lit in that dir,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> am I supposed to build llvm with an addtional param or something in order
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to get it?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Nicklas Bo Jensen <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ok, I've committed now. To only run the AVR
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specific tests run something like:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ./build/Debug+Asserts/bin/llvm-lit
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> llvm/test/CodeGen/AVR/
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 4, 2012 at 1:47 PM, Borja Ferrer
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Oh a small one I've just noticed, leave
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> only 1 newline between tests not 2.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ok they look great now, I don't have any
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> other objections. Please commit this test to SVN, post your SF username
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> here so that Eric or John can give you commit permissions. Once it gets
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> commited I'll check if I need to add any pattern specific tests to it,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> these tests are corner cases of some instructions.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Before commiting it, remove the testcases
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dir with all the files there, and create a new one called test/CodeGen/AVR,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and place your file there, just to keep the same structure like in llvm's
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> repo.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> About the rest of tests to do, from that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> list remove mul and division for now, mul isn't yet implemented and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> division can come later. Sub tests should be very similar to add, then add
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> binary ops (or, and, xor). Add calling convention tests (argument passing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> through regs and stack, return values for each value type, calls). Memory
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> operations, etc...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are quite a few tests to add, but
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for now do the sub and binary op tests and we'll discuss the others by then.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Nicklas Bo Jensen <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1) Sure
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2) Yes, I've followed the msp430 backend
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that does include it. I've removed it now.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3) Again, I've moved the CHECK lines, but
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it differs from backend to backend.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 4) Done
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 5) Done
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 6) Done
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I will continue working other tests,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which do we need? Something like(and please add/comment):
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -Sub
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -division(Only working for multiples of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2?)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -mult
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -Return argument(In a few variants)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -xor
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -increment
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -branching?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Any ideas?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nicklas
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, May 2, 2012 at 12:29 AM, Borja
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ferrer <bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Obviously in the last line I meant adiw
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> or subi/sbci pair, add for immediates doesn't exist for imms greater than 63
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/2 Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> They look good, very nice :)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Some small details and nitpicks:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1) I think it's not necessary to add
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the reg_reg_imm variant because you covered it with the other two tests.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2) Do the tests work if you remove the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> target triple line? I've seen other backends don't include it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3) Move the CHECK lines after the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> function prototype like other backends do.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 4) In every CHECK line, can you remove
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the tabs between the instr mnemonic and the first operand and add a single
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> space? (I'm unsure about this because i dont know if CHECK eats spaces).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Also for the future, the llvm coding standards says to config your editor
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to replace tabs with spaces, so it's a good moment time to do it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 5) Oh and the most important one,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> please add this in only one file, add.ll or something like that, so we can
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> keep this convention in the future, otherwise we'll end having too many
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> test files.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Something that should be covered is,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when doing 16 bit additions we can use adiw or add depending on the imm
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> value, can you cover this aswell?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/1 John Myers <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ato...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sun, Apr 29, 2012 at 10:46 AM,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nicklas Bo Jensen <nbj...@gm...>wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I have successfully been able to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> compile your testcases (/avr-llvm/testcases/*.ll) to something looking like
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> valid avr assembler.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How should I test/simulate the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> assembler? I get errors when trying to simulate the generated assembler in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AVRStudio. Perhaps they use a different assembler?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> avr-llvm produces GNU assembler
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> syntax, which is different then the Atmel assembler syntax.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Eventually we could support multiple
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> asm syntax's like the X86 target does.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
|
|
From: Nicklas Bo J. <nbj...@gm...> - 2012-05-24 21:34:23
|
Sorry for my bad explanations :)
For returning void and returning the first parameter directly the assembly
looks like:
return_void: # @return_void
# BB#0:
ret
What I'm thinking is important to test in these cases is that there is no
code between the label "return_void:" and "ret", only comments.
Here CHECK-NEXT is a good choice, but the two comments makes it much harder
to use CHECK-NEXT. Therefore the first regexp consumes the comment after
the label and the second the comment on the next line, if not including the
first regexp the second will match on the same line as the label.
Does that make sense? Essentially it would be much easier to test if
FileCheck had the option for ignoring comments.
On Thu, May 24, 2012 at 11:03 PM, Borja Ferrer <bor...@gm...>wrote:
> I'm a bit confused now, why is this comment only appearing in this test
> then? I mean, for the rest of tests you didn't need to add that regex.
>
>
> 2012/5/24 Nicklas Bo Jensen <nbj...@gm...>
>
>> The asm looks something like:
>> return_void: # @return_void
>> # BB#0:
>> ret
>>
>> So the two regex's handle one comment each. It's far from perfect, should
>> we just delete these testcases for now?
>>
>> On Thu, May 24, 2012 at 6:40 PM, Borja Ferrer <bor...@gm...>wrote:
>>
>>> I prefer the second, although it's a bit nasty it doesn't use an
>>> external tool. For what is this regex used in CHECK:
>>> return_void:{{[a-zA-Z0-9 #@]*}} ?
>>>
>>>
>>> 2012/5/24 Nicklas Bo Jensen <nbj...@gm...>
>>>
>>>> I agree. FileCheck should be able to ignore comments(at least as a
>>>> parameter) like it ignores whitespaces.
>>>>
>>>> However I do have a few suggestions for how to do it, if you like one
>>>> of them we can use it.
>>>>
>>>> 1. Previous suggestion with "hardcoded" comment.
>>>> 2. Accept any comment after label:
>>>> define void @return_void() {
>>>> ; CHECK: return_void:{{[a-zA-Z0-9 #@]*}}
>>>> ; CHECK-NEXT: #{{[a-zA-Z0-9 #@]*}}
>>>> ; CHECK-NEXT: ret
>>>> ret void
>>>> }
>>>>
>>>> 3. Strip the assembler for comments and blank lines(here using sed)
>>>> before checking.
>>>> ; RUN: llc < %s -march=avr | sed "s/#.*//" | sed "/^$/d" | FileCheck %s
>>>>
>>>> define void @return_void() {
>>>> ; CHECK: return_void:
>>>> ; CHECK-NEXT: ret
>>>> ret void
>>>> }
>>>>
>>>> 2. is a bit complex and if we later choose to not print comments before
>>>> blocks the test will fail.
>>>> 3. is simpler, but requires a third party tool.
>>>>
>>>> What do you think Borja? I haven't found another backend dealing with
>>>> this issue.
>>>>
>>>>
>>>> On Thu, May 24, 2012 at 12:33 PM, Borja Ferrer <bor...@gm...>wrote:
>>>>
>>>>> I like it but checking for BB#0 is a bit nasty because it's a comment
>>>>> and not an instruction, also that could change in the future breaking the
>>>>> test.
>>>>>
>>>>> I've checked the other backends and we're testing things further than
>>>>> what others do so I think there's no need for more tests there.
>>>>>
>>>>>
>>>>> 2012/5/24 Nicklas Bo Jensen <nbj...@gm...>
>>>>>
>>>>>> One idea could be to use CHECK-NEXT that checks if the string is on a
>>>>>> consecutive line, then we could do something like:
>>>>>>
>>>>>> define void @return_void() {
>>>>>> ; CHECK: return_void:
>>>>>> ; CHECK-NEXT: # BB#0:
>>>>>> ; CHECK-NEXT: ret
>>>>>> ret void
>>>>>> }
>>>>>>
>>>>>> The solution with the comment is not the best. What do you think?
>>>>>>
>>>>>>
>>>>>> On Thu, May 24, 2012 at 1:48 AM, Borja Ferrer <bor...@gm...>wrote:
>>>>>>
>>>>>>> Maybe you could check using CHECKNOT or whatever to make sure that
>>>>>>> no moves are emitted, that would cover it.
>>>>>>>
>>>>>>> I'll check what other backends do regarding these tests and see if I
>>>>>>> can come up with further things.
>>>>>>>
>>>>>>>
>>>>>>> 2012/5/23 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>
>>>>>>>> Are the following tests obsolete, as there in my opinion is no
>>>>>>>> really good way to test them using FileCheck(with my current return
>>>>>>>> tests(included) we could return the wrong argument)?
>>>>>>>>
>>>>>>>> - Returning void.
>>>>>>>> - Returning the first parameter, which is already in the
>>>>>>>> correct place.
>>>>>>>>
>>>>>>>>
>>>>>>>> Do we need additional tests for returning, besides
>>>>>>>> returning immediate and argument, like returning a value from register or
>>>>>>>> is it already covered in returning a argument?
>>>>>>>>
>>>>>>>> On Wed, May 23, 2012 at 12:51 AM, Borja Ferrer <
>>>>>>>> bor...@gm...> wrote:
>>>>>>>>
>>>>>>>>> Yes, that's something handled by llvm, not the backend so we can't
>>>>>>>>> do too much there, although it would be a nice optimization to do.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2012/5/23 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>
>>>>>>>>>> Thanks for the explanation. It's clear :)
>>>>>>>>>>
>>>>>>>>>> Out of curiosity, why are the pushes and pops in the example
>>>>>>>>>> below? movw leaves r17:r14 unchanged. Do we simply push and pop all
>>>>>>>>>> registers to be on the safe side and limited static analysis?
>>>>>>>>>>
>>>>>>>>>> llvm:
>>>>>>>>>> define i32 @return32_arg2(i32 %x, i32 %y, i32 %z) {
>>>>>>>>>> ret i32 %z
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> asm:
>>>>>>>>>> return32_arg2:
>>>>>>>>>> push r14
>>>>>>>>>> push r15
>>>>>>>>>> push r16
>>>>>>>>>> push r17
>>>>>>>>>> movw r23:r22, r15:r14
>>>>>>>>>> movw r25:r24, r17:r16
>>>>>>>>>> pop r17
>>>>>>>>>> pop r16
>>>>>>>>>> pop r15
>>>>>>>>>> pop r14
>>>>>>>>>>
>>>>>>>>>> On Tue, May 22, 2012 at 11:32 PM, Borja Ferrer <
>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>
>>>>>>>>>>> Here you have a link that explains how registers are used:
>>>>>>>>>>> www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_reg_usage
>>>>>>>>>>> Testing a calling convention without knowing how it actually
>>>>>>>>>>> works is going to be an insane task to do xD
>>>>>>>>>>>
>>>>>>>>>>> About your question, when you read that link all will become
>>>>>>>>>>> clear but basically here is what's going on. Arguments are passed from r25
>>>>>>>>>>> down to r8, since in this case three 64bit args can't fit in those
>>>>>>>>>>> registers the last argument is passed through the stack, so you get:
>>>>>>>>>>> arg1 is in: r25-r18
>>>>>>>>>>> arg2 is in: r17-r10
>>>>>>>>>>> arg3 obviously doesn't fit in 2 register so it's all passed
>>>>>>>>>>> through the stack, thats why you get those loads. Notice that the lowest
>>>>>>>>>>> part of the argument is in Y+5 because in +4 and +3 is r29:r28 you just
>>>>>>>>>>> pushed and in +2 +1 is the the return address that was pushed into the
>>>>>>>>>>> stack after the call was performed.
>>>>>>>>>>>
>>>>>>>>>>> Another thing, you should add checks on the pushes and pops for
>>>>>>>>>>> the callee saved registers so we're sure that they're being saved.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2012/5/22 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>
>>>>>>>>>>>> Perfect :)
>>>>>>>>>>>>
>>>>>>>>>>>> I'm moving on to calling convention and have started with
>>>>>>>>>>>> return values. However I'm a bit unsure what the calling convention
>>>>>>>>>>>> actually is. For example with my last test, called "return64_arg2" in the
>>>>>>>>>>>> attached .ll file and the generated assembly in the .s file, is the correct
>>>>>>>>>>>> thing happening and how it should be tested? Couldn't we have passed the
>>>>>>>>>>>> arguments in the normal registers? I.e. r25:r2.
>>>>>>>>>>>>
>>>>>>>>>>>> If the arguments don't fit in the registers, do we always store
>>>>>>>>>>>> the result in the same place in ram?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, May 21, 2012 at 11:38 PM, Borja Ferrer <
>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Nice, so now you have the same test failures as me, they are
>>>>>>>>>>>>> caused because we're using custom address space stuff in clang, dont worry
>>>>>>>>>>>>> about those. Basically they fail because these tests are writing into
>>>>>>>>>>>>> address space 1 which is flash data and that is forbidden in our target
>>>>>>>>>>>>> (remember flash memory is readonly).
>>>>>>>>>>>>>
>>>>>>>>>>>>> The test cases you just commited look great :) To which ones
>>>>>>>>>>>>> are you going to move on next?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, that code looks correct, where is the problem?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2012/5/21 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is the following generated code correct:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> LLVM:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> define i8 @return8_arg(i8 %x) {
>>>>>>>>>>>>>> ret i8 %x
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Generated:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> return8_arg:
>>>>>>>>>>>>>> ret
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Something similar in .c compiling with avr-gcc gives a few
>>>>>>>>>>>>>> pushes, loads and pops.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, May 21, 2012 at 10:48 PM, Nicklas Bo Jensen <
>>>>>>>>>>>>>> nbj...@gm...> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When adding those targets I only have 10 unexpected failures:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Clang :: CodeGen/address-space-compound-literal.c
>>>>>>>>>>>>>>> Clang :: CodeGen/address-space-field1.c
>>>>>>>>>>>>>>> Clang :: CodeGen/address-space.c
>>>>>>>>>>>>>>> Clang :: CodeGenCXX/mangle-address-space.cpp
>>>>>>>>>>>>>>> Clang :: PCH/types.c
>>>>>>>>>>>>>>> Clang :: Sema/address_spaces.c
>>>>>>>>>>>>>>> Clang :: SemaCXX/address-space-conversion.cpp
>>>>>>>>>>>>>>> Clang :: SemaCXX/address-space-newdelete.cpp
>>>>>>>>>>>>>>> Clang :: SemaCXX/address-space-references.cpp
>>>>>>>>>>>>>>> Clang :: SemaTemplate/address-spaces.cpp
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I will try to run each test separately and try to figure out
>>>>>>>>>>>>>>> why they are failing. I have also attached the test output.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm also committing tests for and, or and xor in a minute.
>>>>>>>>>>>>>>> They are really simple and similar to the add and sub tests. Please review
>>>>>>>>>>>>>>> these :)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, May 14, 2012 at 11:32 PM, Borja Ferrer <
>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Did you try adding the x86 and x64 targets with the avr
>>>>>>>>>>>>>>>> one? It's something related with an unsopported target.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Good question, I think there's no need to do reg+imm for
>>>>>>>>>>>>>>>> xor.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Btw remember to add the SF mailing list so we can have a
>>>>>>>>>>>>>>>> record ;)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2012/5/14 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Sorry, that is the llvm+clang trunk gives me 13
>>>>>>>>>>>>>>>>> unsupported tests, i.e. no failures versus the avr-llvm giving me 280
>>>>>>>>>>>>>>>>> unexpected failures.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Mon, May 14, 2012 at 9:08 PM, Nicklas Bo Jensen <
>>>>>>>>>>>>>>>>> nbj...@gm...> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> BTW, the newest llvm and clang trunk only gives me 13
>>>>>>>>>>>>>>>>>> unexpected failures compared to the the newest trunk with avr-llvm where i
>>>>>>>>>>>>>>>>>> get 280 unexpected failures.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Considering the regression tests for xor, does it make
>>>>>>>>>>>>>>>>>> sense to test reg+imm, as the avr assembler does not have xor for immediate?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Thu, May 10, 2012 at 9:12 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I don't think so, but I configured llvm to support both
>>>>>>>>>>>>>>>>>>> x86 and x64, so maybe that could help, in fact I can't build clang if I
>>>>>>>>>>>>>>>>>>> don't add support for x86.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2012/5/10 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Target: x86_64-unknown-linux-gnu
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> But I only configured for avr... Did I do something
>>>>>>>>>>>>>>>>>>>> wrong?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Thu, May 10, 2012 at 5:32 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> This is what I'm getting:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Expected Passes : 9914
>>>>>>>>>>>>>>>>>>>>> Expected Failures : 66
>>>>>>>>>>>>>>>>>>>>> Unsupported Tests : 569
>>>>>>>>>>>>>>>>>>>>> Unexpected Failures: 11
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I've seen in that file you attached that you're
>>>>>>>>>>>>>>>>>>>>> getting errors because of the target triple, errors like:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> error: unable to create target: 'No available targets are compatible with this triple, see -version for the available targets.'
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> error auto-selecting target for module 'No available targets are compatible with this triple, see -version for the available targets
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> so I guess that's the reason, so what is your target
>>>>>>>>>>>>>>>>>>>>> triple? do clang -v to get it, mine is i386-pc-linux-gnu
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2012/5/10 Borja Ferrer <bor...@gm...>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Interesting, I'll check it out tomorrow to see if I
>>>>>>>>>>>>>>>>>>>>>> can find some reason behind this, because we're getting very different
>>>>>>>>>>>>>>>>>>>>>> results here.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 2012/5/9 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Sorry for my slow response.Got i working again now,
>>>>>>>>>>>>>>>>>>>>>>> thanks.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Building with optimization disabled and assertions
>>>>>>>>>>>>>>>>>>>>>>> turned on i get:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Avr llvm+clang:
>>>>>>>>>>>>>>>>>>>>>>> Expected Passes : 6978
>>>>>>>>>>>>>>>>>>>>>>> Expected Failures : 39
>>>>>>>>>>>>>>>>>>>>>>> Unsupported Tests : 3281
>>>>>>>>>>>>>>>>>>>>>>> Unexpected Failures: 279
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> In the 279 unexpected failures for example 143 of
>>>>>>>>>>>>>>>>>>>>>>> them are test/CodeGen/Generic. I'm not really sure how these tests are
>>>>>>>>>>>>>>>>>>>>>>> supposed to work? None of them seems to be using FileCheck.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> However building for msp430 seems to be giving me
>>>>>>>>>>>>>>>>>>>>>>> similar results, indicating that it is not a avr-llvm specific problem.
>>>>>>>>>>>>>>>>>>>>>>> Please see the attached output "make check-all" from avr-llvm.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 4, 2012 at 11:30 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I'm asking because last week you said that you were
>>>>>>>>>>>>>>>>>>>>>>>> getting +200 fails, and since I'm getting 11 I wanted to know what's going
>>>>>>>>>>>>>>>>>>>>>>>> on.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> faluco is me btw, I updated a patch today because I
>>>>>>>>>>>>>>>>>>>>>>>> got a conflict when updating my clang repo. These variables are defined in
>>>>>>>>>>>>>>>>>>>>>>>> DiagnosticSemaKinds.td so check that you have them, they come from the
>>>>>>>>>>>>>>>>>>>>>>>> flash.diff patch.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> The new tests should pass. I cannot check other
>>>>>>>>>>>>>>>>>>>>>>>>> tests now, I'm having some issues after applying the newest patches that
>>>>>>>>>>>>>>>>>>>>>>>>> came in today by faluco:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> /home/nicklas/install/avr-llvm/llvm/tools/clang/lib/Sema/SemaDecl.cpp:4374:38:
>>>>>>>>>>>>>>>>>>>>>>>>> error:
>>>>>>>>>>>>>>>>>>>>>>>>> no member named
>>>>>>>>>>>>>>>>>>>>>>>>> 'err_flash_variable_requires_const' in namespace
>>>>>>>>>>>>>>>>>>>>>>>>> 'clang::diag'
>>>>>>>>>>>>>>>>>>>>>>>>> Diag(NewVD->getLocation(),
>>>>>>>>>>>>>>>>>>>>>>>>> diag::err_flash_variable_requires_const);
>>>>>>>>>>>>>>>>>>>>>>>>> ~~~~~~^
>>>>>>>>>>>>>>>>>>>>>>>>> /home/nicklas/install/avr-llvm/llvm/tools/clang/lib/Sema/SemaDecl.cpp:4383:38:
>>>>>>>>>>>>>>>>>>>>>>>>> error:
>>>>>>>>>>>>>>>>>>>>>>>>> no member named
>>>>>>>>>>>>>>>>>>>>>>>>> 'err_flash_pointer_requires_const' in namespace
>>>>>>>>>>>>>>>>>>>>>>>>> 'clang::diag'
>>>>>>>>>>>>>>>>>>>>>>>>> Diag(NewVD->getLocation(),
>>>>>>>>>>>>>>>>>>>>>>>>> diag::err_flash_pointer_requires_const);
>>>>>>>>>>>>>>>>>>>>>>>>> ~~~~~~^
>>>>>>>>>>>>>>>>>>>>>>>>> /home/nicklas/install/avr-llvm/llvm/tools/clang/lib/Sema/SemaDecl.cpp:7208:25:
>>>>>>>>>>>>>>>>>>>>>>>>> error:
>>>>>>>>>>>>>>>>>>>>>>>>> no member named
>>>>>>>>>>>>>>>>>>>>>>>>> 'err_flash_pointer_requires_const' in namespace
>>>>>>>>>>>>>>>>>>>>>>>>> 'clang::diag'
>>>>>>>>>>>>>>>>>>>>>>>>> Diag(NameLoc,
>>>>>>>>>>>>>>>>>>>>>>>>> diag::err_flash_pointer_requires_const);
>>>>>>>>>>>>>>>>>>>>>>>>> ~~~~~~^
>>>>>>>>>>>>>>>>>>>>>>>>> Have i done something wrong?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>> Nicklas
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 4, 2012 at 8:50 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> How many tests failures are you getting now?
>>>>>>>>>>>>>>>>>>>>>>>>>> I'm getting 11, 10 from clang due to address
>>>>>>>>>>>>>>>>>>>>>>>>>> space stuff (you'll need to patch clang to get those) and 1 from llvm.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Ah, perfect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> I would actually guess that you need to run
>>>>>>>>>>>>>>>>>>>>>>>>>>> "make check-all" before being able to test new tests individually. Sorry :)
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 4, 2012 at 8:17 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nevermind, got it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Borja Ferrer <bor...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> One thing, i dont have llvm-lit in that dir,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> am I supposed to build llvm with an addtional param or something in order
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to get it?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Nicklas Bo Jensen <nbj...@gm...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ok, I've committed now. To only run the AVR
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specific tests run something like:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ./build/Debug+Asserts/bin/llvm-lit
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> llvm/test/CodeGen/AVR/
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 4, 2012 at 1:47 PM, Borja Ferrer
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Oh a small one I've just noticed, leave only
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1 newline between tests not 2.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Borja Ferrer <bor...@gm...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ok they look great now, I don't have any
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> other objections. Please commit this test to SVN, post your SF username
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> here so that Eric or John can give you commit permissions. Once it gets
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> commited I'll check if I need to add any pattern specific tests to it,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> these tests are corner cases of some instructions.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Before commiting it, remove the testcases
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dir with all the files there, and create a new one called test/CodeGen/AVR,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and place your file there, just to keep the same structure like in llvm's
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> repo.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> About the rest of tests to do, from that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> list remove mul and division for now, mul isn't yet implemented and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> division can come later. Sub tests should be very similar to add, then add
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> binary ops (or, and, xor). Add calling convention tests (argument passing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> through regs and stack, return values for each value type, calls). Memory
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> operations, etc...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are quite a few tests to add, but for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> now do the sub and binary op tests and we'll discuss the others by then.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Nicklas Bo Jensen <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1) Sure
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2) Yes, I've followed the msp430 backend
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that does include it. I've removed it now.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3) Again, I've moved the CHECK lines, but
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it differs from backend to backend.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 4) Done
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 5) Done
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 6) Done
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I will continue working other tests, which
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> do we need? Something like(and please add/comment):
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -Sub
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -division(Only working for multiples of 2?)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -mult
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -Return argument(In a few variants)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -xor
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -increment
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -branching?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Any ideas?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nicklas
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, May 2, 2012 at 12:29 AM, Borja
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ferrer <bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Obviously in the last line I meant adiw
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> or subi/sbci pair, add for immediates doesn't exist for imms greater than 63
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/2 Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> They look good, very nice :)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Some small details and nitpicks:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1) I think it's not necessary to add the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reg_reg_imm variant because you covered it with the other two tests.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2) Do the tests work if you remove the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> target triple line? I've seen other backends don't include it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3) Move the CHECK lines after the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> function prototype like other backends do.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 4) In every CHECK line, can you remove
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the tabs between the instr mnemonic and the first operand and add a single
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> space? (I'm unsure about this because i dont know if CHECK eats spaces).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Also for the future, the llvm coding standards says to config your editor
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to replace tabs with spaces, so it's a good moment time to do it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 5) Oh and the most important one, please
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> add this in only one file, add.ll or something like that, so we can keep
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this convention in the future, otherwise we'll end having too many test
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> files.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Something that should be covered is,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when doing 16 bit additions we can use adiw or add depending on the imm
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> value, can you cover this aswell?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/1 John Myers <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ato...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sun, Apr 29, 2012 at 10:46 AM,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nicklas Bo Jensen <nbj...@gm...>wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I have successfully been able to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> compile your testcases (/avr-llvm/testcases/*.ll) to something looking like
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> valid avr assembler.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How should I test/simulate the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> assembler? I get errors when trying to simulate the generated assembler in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AVRStudio. Perhaps they use a different assembler?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> avr-llvm produces GNU assembler
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> syntax, which is different then the Atmel assembler syntax.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Eventually we could support multiple
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> asm syntax's like the X86 target does.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
|
|
From: Borja F. <bor...@gm...> - 2012-05-24 21:03:43
|
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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
|
|
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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
|
|
From: Borja F. <bor...@gm...> - 2012-05-24 16:41:01
|
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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
|
|
From: Nicklas Bo J. <nbj...@gm...> - 2012-05-24 14:21:04
|
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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
|
|
From: Borja F. <bor...@gm...> - 2012-05-24 10:33:09
|
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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
|
|
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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
|
|
From: Borja F. <bor...@gm...> - 2012-05-23 23:48:52
|
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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
|
14 messages has been excluded from this view by a project administrator.
