Menu
▾
▴
avr-llvm-devel
|
From: John M. <ato...@gm...> - 2012-02-26 04:37:40
|
On Wed, Feb 22, 2012 at 4:34 PM, Borja Ferrer <bor...@gm...> wrote:
> No comments yet?
>
I'm getting the below error. Are there other patches that haven't been
committed or is this just a mis-match between the LLVM trunk and avr-llvm?
llvm[3]: Compiling AVRFrameLowering.cpp for Release+Asserts build
llvm[3]: Compiling AVRISelDAGToDAG.cpp for Release+Asserts build
llvm[3]: Compiling AVRISelLowering.cpp for Release+Asserts build
AVRISelLowering.cpp:762:12: error: assigning to 'llvm::TargetRegisterClass
*' from incompatible type 'const llvm::TargetRegisterClass *const'
RC = AVR::GPR8RegisterClass;
^ ~~~~~~~~~~~~~~~~~~~~~~
AVRISelLowering.cpp:766:12: error: assigning to 'llvm::TargetRegisterClass
*' from incompatible type 'const llvm::TargetRegisterClass *const'
RC = AVR::DREGSRegisterClass;
^ ~~~~~~~~~~~~~~~~~~~~~~~
2 errors generated.
|
|
From: Borja F. <bor...@gm...> - 2012-02-26 14:00:58
|
I don't think so John, I'll take a look. This compiled last week when I committed it perfectly so maybe there's been some change during this week than has broken the build. I assume this happens to you with latest LLVM trunk revision? 2012/2/26 John Myers <ato...@gm...> > > > On Wed, Feb 22, 2012 at 4:34 PM, Borja Ferrer <bor...@gm...>wrote: > >> No comments yet? >> > > I'm getting the below error. Are there other patches that haven't been > committed or is this just a mis-match between the LLVM trunk and avr-llvm? > > llvm[3]: Compiling AVRFrameLowering.cpp for Release+Asserts build > llvm[3]: Compiling AVRISelDAGToDAG.cpp for Release+Asserts build > llvm[3]: Compiling AVRISelLowering.cpp for Release+Asserts build > AVRISelLowering.cpp:762:12: error: assigning to 'llvm::TargetRegisterClass > *' from incompatible type 'const llvm::TargetRegisterClass *const' > RC = AVR::GPR8RegisterClass; > ^ ~~~~~~~~~~~~~~~~~~~~~~ > AVRISelLowering.cpp:766:12: error: assigning to 'llvm::TargetRegisterClass > *' from incompatible type 'const llvm::TargetRegisterClass *const' > RC = AVR::DREGSRegisterClass; > ^ ~~~~~~~~~~~~~~~~~~~~~~~ > 2 errors generated. > > |
|
From: Borja F. <bor...@gm...> - 2012-02-26 14:38:56
|
Ok, fixed. This was caused by rev151134 where they changed the format on how register classes are printed with tablegen, making RC a const pointer. 2012/2/26 Borja Ferrer <bor...@gm...> > I don't think so John, I'll take a look. This compiled last week when I > committed it perfectly so maybe there's been some change during this week > than has broken the build. I assume this happens to you with latest LLVM > trunk revision? > > > 2012/2/26 John Myers <ato...@gm...> > >> >> >> On Wed, Feb 22, 2012 at 4:34 PM, Borja Ferrer <bor...@gm...>wrote: >> >>> No comments yet? >>> >> >> I'm getting the below error. Are there other patches that haven't been >> committed or is this just a mis-match between the LLVM trunk and avr-llvm? >> >> llvm[3]: Compiling AVRFrameLowering.cpp for Release+Asserts build >> llvm[3]: Compiling AVRISelDAGToDAG.cpp for Release+Asserts build >> llvm[3]: Compiling AVRISelLowering.cpp for Release+Asserts build >> AVRISelLowering.cpp:762:12: error: assigning to >> 'llvm::TargetRegisterClass *' from incompatible type 'const >> llvm::TargetRegisterClass *const' >> RC = AVR::GPR8RegisterClass; >> ^ ~~~~~~~~~~~~~~~~~~~~~~ >> AVRISelLowering.cpp:766:12: error: assigning to >> 'llvm::TargetRegisterClass *' from incompatible type 'const >> llvm::TargetRegisterClass *const' >> RC = AVR::DREGSRegisterClass; >> ^ ~~~~~~~~~~~~~~~~~~~~~~~ >> 2 errors generated. >> >> > |
|
From: Borja F. <bor...@gm...> - 2012-03-04 13:35:22
|
John, can you update the RegAllocGreedy patch file with last night changes? You have to change the AliasI variable in the for loop to be of type uint16_t * instead of unsigned *. 2012/2/26 Borja Ferrer <bor...@gm...> > Ok, fixed. This was caused by rev151134 where they changed the format on > how register classes are printed with tablegen, making RC a const pointer. > > > 2012/2/26 Borja Ferrer <bor...@gm...> > >> I don't think so John, I'll take a look. This compiled last week when I >> committed it perfectly so maybe there's been some change during this week >> than has broken the build. I assume this happens to you with latest LLVM >> trunk revision? >> >> >> 2012/2/26 John Myers <ato...@gm...> >> >>> >>> >>> On Wed, Feb 22, 2012 at 4:34 PM, Borja Ferrer <bor...@gm...>wrote: >>> >>>> No comments yet? >>>> >>> >>> I'm getting the below error. Are there other patches that haven't been >>> committed or is this just a mis-match between the LLVM trunk and avr-llvm? >>> >>> llvm[3]: Compiling AVRFrameLowering.cpp for Release+Asserts build >>> llvm[3]: Compiling AVRISelDAGToDAG.cpp for Release+Asserts build >>> llvm[3]: Compiling AVRISelLowering.cpp for Release+Asserts build >>> AVRISelLowering.cpp:762:12: error: assigning to >>> 'llvm::TargetRegisterClass *' from incompatible type 'const >>> llvm::TargetRegisterClass *const' >>> RC = AVR::GPR8RegisterClass; >>> ^ ~~~~~~~~~~~~~~~~~~~~~~ >>> AVRISelLowering.cpp:766:12: error: assigning to >>> 'llvm::TargetRegisterClass *' from incompatible type 'const >>> llvm::TargetRegisterClass *const' >>> RC = AVR::DREGSRegisterClass; >>> ^ ~~~~~~~~~~~~~~~~~~~~~~~ >>> 2 errors generated. >>> >>> >> > |
|
From: Borja F. <bor...@gm...> - 2012-03-04 21:34:05
|
John check the lastest patch files I've just commited to see if they patch correctly or i've messed them. Btw, have you been able to try the backend? 2012/3/4 Borja Ferrer <bor...@gm...> > John, can you update the RegAllocGreedy patch file with last night > changes? You have to change the AliasI variable in the for loop to be of > type uint16_t * instead of unsigned *. > > > 2012/2/26 Borja Ferrer <bor...@gm...> > >> Ok, fixed. This was caused by rev151134 where they changed the format on >> how register classes are printed with tablegen, making RC a const pointer. >> >> >> 2012/2/26 Borja Ferrer <bor...@gm...> >> >>> I don't think so John, I'll take a look. This compiled last week when I >>> committed it perfectly so maybe there's been some change during this week >>> than has broken the build. I assume this happens to you with latest LLVM >>> trunk revision? >>> >>> >>> 2012/2/26 John Myers <ato...@gm...> >>> >>>> >>>> >>>> On Wed, Feb 22, 2012 at 4:34 PM, Borja Ferrer <bor...@gm...>wrote: >>>> >>>>> No comments yet? >>>>> >>>> >>>> I'm getting the below error. Are there other patches that haven't been >>>> committed or is this just a mis-match between the LLVM trunk and avr-llvm? >>>> >>>> llvm[3]: Compiling AVRFrameLowering.cpp for Release+Asserts build >>>> llvm[3]: Compiling AVRISelDAGToDAG.cpp for Release+Asserts build >>>> llvm[3]: Compiling AVRISelLowering.cpp for Release+Asserts build >>>> AVRISelLowering.cpp:762:12: error: assigning to >>>> 'llvm::TargetRegisterClass *' from incompatible type 'const >>>> llvm::TargetRegisterClass *const' >>>> RC = AVR::GPR8RegisterClass; >>>> ^ ~~~~~~~~~~~~~~~~~~~~~~ >>>> AVRISelLowering.cpp:766:12: error: assigning to >>>> 'llvm::TargetRegisterClass *' from incompatible type 'const >>>> llvm::TargetRegisterClass *const' >>>> RC = AVR::DREGSRegisterClass; >>>> ^ ~~~~~~~~~~~~~~~~~~~~~~~ >>>> 2 errors generated. >>>> >>>> >>> >> > |
|
From: John M. <ato...@gm...> - 2012-03-05 00:40:05
|
On Sun, Mar 4, 2012 at 1:33 PM, Borja Ferrer <bor...@gm...> wrote:
> John check the lastest patch files I've just commited to see if they patch
> correctly or i've messed them.
> Btw, have you been able to try the backend?
>
They all apply cleanly but you have to hunt around to find which directory
to start in for each file. I'm going to combine them into one patch that
can be applied from the root directory.
I haven't really looked at the backend yet . I did notice that there was a
pseudo instruction (spload) that made it into the assembly file which
stopped avr-gcc from being able to assemble it though.
main:
push r28
push r29
spload r29:r28, SP
sbiw r29:r28, 2
ldi r24, 0
ldi r25, 0
std Y+1, r24
std Y+2, r25
spload r29:r28, SP
adiw r29:r28, 2
pop r29
pop r28
ret
|
|
From: Borja F. <bor...@gm...> - 2012-03-05 20:25:50
|
For now, spload should be the only pseudo that is allowed to get into assembly, if you see any other pseudo it is a bug. Expanding spload into real instructions requires a bit of work that is currently unimplemented, so for now we'll have to live with it. I hope it's not a big deal for you. About the patches, it's a good idea what you said, feel free to do it when you have time. I still have to add some more patches about interrupts. 2012/3/5 John Myers <ato...@gm...> > On Sun, Mar 4, 2012 at 1:33 PM, Borja Ferrer <bor...@gm...>wrote: > >> John check the lastest patch files I've just commited to see if they >> patch correctly or i've messed them. >> Btw, have you been able to try the backend? >> > > They all apply cleanly but you have to hunt around to find which directory > to start in for each file. I'm going to combine them into one patch that > can be applied from the root directory. > > > I haven't really looked at the backend yet . I did notice that there was a > pseudo instruction (spload) that made it into the assembly file which > stopped avr-gcc from being able to assemble it though. > > main: > push r28 > push r29 > spload r29:r28, SP > sbiw r29:r28, 2 > ldi r24, 0 > ldi r25, 0 > std Y+1, r24 > std Y+2, r25 > spload r29:r28, SP > adiw r29:r28, 2 > pop r29 > pop r28 > ret > > |
|
From: Borja F. <bor...@gm...> - 2012-03-05 21:11:32
|
Ah John one more thing, you may want to combine SelectionDAGBuilder.diff<http://avr-llvm.svn.sourceforge.net/viewvc/avr-llvm/llvm/trunk/patches/SelectionDAGBuilder.diff?sortby=date&view=log>and TargetCallingConv.diff<http://avr-llvm.svn.sourceforge.net/viewvc/avr-llvm/llvm/trunk/patches/TargetCallingConv.diff?sortby=date&view=log>into one file since they both are used for the same purpose, you can name the patch SplitArgPiece 2012/3/5 Borja Ferrer <bor...@gm...> > For now, spload should be the only pseudo that is allowed to get into > assembly, if you see any other pseudo it is a bug. Expanding spload into > real instructions requires a bit of work that is currently unimplemented, > so for now we'll have to live with it. I hope it's not a big deal for you. > > About the patches, it's a good idea what you said, feel free to do it when > you have time. I still have to add some more patches about interrupts. > > > 2012/3/5 John Myers <ato...@gm...> > >> On Sun, Mar 4, 2012 at 1:33 PM, Borja Ferrer <bor...@gm...>wrote: >> >>> John check the lastest patch files I've just commited to see if they >>> patch correctly or i've messed them. >>> Btw, have you been able to try the backend? >>> >> >> They all apply cleanly but you have to hunt around to find which >> directory to start in for each file. I'm going to combine them into one >> patch that can be applied from the root directory. >> >> >> I haven't really looked at the backend yet . I did notice that there was >> a pseudo instruction (spload) that made it into the assembly file which >> stopped avr-gcc from being able to assemble it though. >> >> main: >> push r28 >> push r29 >> spload r29:r28, SP >> sbiw r29:r28, 2 >> ldi r24, 0 >> ldi r25, 0 >> std Y+1, r24 >> std Y+2, r25 >> spload r29:r28, SP >> adiw r29:r28, 2 >> pop r29 >> pop r28 >> ret >> >> > |
|
From: Weddington, E. <Eri...@at...> - 2012-03-09 04:24:11
|
Hi Borja, Yes, there is a certain order. It's one way for reading, and another for writing. And then, for the xmega devices, it gets switched around for one of the operations. :-P Unfortunately, I can't remember off the top of my head which is which. I'll have to go take a look at the AVR GCC backend code to refresh my memory... Eric > -----Original Message----- > From: Borja Ferrer [mailto:bor...@gm...] > Sent: Wednesday, March 07, 2012 2:38 PM > To: John Myers > Cc: avr...@li... > Subject: Re: [avr-llvm-devel] Current Status? > > Eric, one question. I vaguely remember that when reading or writing (i can't > remember if both) a 16 bit variable from RAM there was a certain order, MSByte > first then LSByte or the other way round. Can you clarify this information for > me and where is this specified and for which memory space this happens. > > > 2012/3/5 Borja Ferrer <bor...@gm...> > > > Ah John one more thing, you may want to combine SelectionDAGBuilder.diff > and TargetCallingConv.diff into one file since they both are used for the same > purpose, you can name the patch SplitArgPiece > > > 2012/3/5 Borja Ferrer <bor...@gm...> > > > For now, spload should be the only pseudo that is allowed to get > into assembly, if you see any other pseudo it is a bug. Expanding spload into > real instructions requires a bit of work that is currently unimplemented, so > for now we'll have to live with it. I hope it's not a big deal for you. > > About the patches, it's a good idea what you said, feel free to do > it when you have time. I still have to add some more patches about interrupts. > > > 2012/3/5 John Myers <ato...@gm...> > > > On Sun, Mar 4, 2012 at 1:33 PM, Borja Ferrer > <bor...@gm...> wrote: > > > John check the lastest patch files I've just commited > to see if they patch correctly or i've messed them. > Btw, have you been able to try the backend? > > > They all apply cleanly but you have to hunt around to find > which directory to start in for each file. I'm going to combine them into one > patch that can be applied from the root directory. > > > I haven't really looked at the backend yet . I did notice > that there was a pseudo instruction (spload) that made it into the assembly > file which stopped avr-gcc from being able to assemble it though. > > main: > push r28 > push r29 > spload r29:r28, SP > sbiw r29:r28, 2 > ldi r24, 0 > ldi r25, 0 > std Y+1, r24 > std Y+2, r25 > spload r29:r28, SP > adiw r29:r28, 2 > pop r29 > pop r28 > ret > > > > > |
|
From: Borja F. <bor...@gm...> - 2012-03-09 13:02:04
|
This is what I've found in atmega's 644pa datasheet: 1) when reading do LSByte first 2) when writing do MSByte first It explains the order is very important because there's some temp register when reading/writing some registers of the 16bit timers that gets activated with this particular order. Since these regs are present up to address 0xff then all in/out instructions should follow this order. Also LDS/STS instructions that use this address range should follow this order for addresses between 0x60 and 0xff, I think that making all sts/lds instructions follow this order instead of that specific range is ok, i can't think of a penalty of doing this. Now things get a bit harder for ld/st instructions because there's no way to know what is the actual address being used. Reversing the order is not good because it messes up postinc or predec operations, maybe only reverse the order if the address is volatile? just an idea. As an example IAR doesn't care at all, it only reverses in/out instructions, so unless I'm missing something it's going to produce wrong code. 2012/3/9 Weddington, Eric <Eri...@at...> > Hi Borja, > > Yes, there is a certain order. It's one way for reading, and another for > writing. And then, for the xmega devices, it gets switched around for > one of the operations. :-P > > Unfortunately, I can't remember off the top of my head which is which. > I'll have to go take a look at the AVR GCC backend code to refresh my > memory... > > Eric > > > -----Original Message----- > > From: Borja Ferrer [mailto:bor...@gm...] > > Sent: Wednesday, March 07, 2012 2:38 PM > > To: John Myers > > Cc: avr...@li... > > Subject: Re: [avr-llvm-devel] Current Status? > > > > Eric, one question. I vaguely remember that when reading or writing (i > can't > > remember if both) a 16 bit variable from RAM there was a certain > order, MSByte > > first then LSByte or the other way round. Can you clarify this > information for > > me and where is this specified and for which memory space this > happens. > > > > > > 2012/3/5 Borja Ferrer <bor...@gm...> > > > > > > Ah John one more thing, you may want to combine > SelectionDAGBuilder.diff > > and TargetCallingConv.diff into one file since they both are used for > the same > > purpose, you can name the patch SplitArgPiece > > > > > > 2012/3/5 Borja Ferrer <bor...@gm...> > > > > > > For now, spload should be the only pseudo that is > allowed to get > > into assembly, if you see any other pseudo it is a bug. Expanding > spload into > > real instructions requires a bit of work that is currently > unimplemented, so > > for now we'll have to live with it. I hope it's not a big deal for > you. > > > > About the patches, it's a good idea what you said, feel > free to do > > it when you have time. I still have to add some more patches about > interrupts. > > > > > > 2012/3/5 John Myers <ato...@gm...> > > > > > > On Sun, Mar 4, 2012 at 1:33 PM, Borja Ferrer > > <bor...@gm...> wrote: > > > > > > John check the lastest patch files I've > just commited > > to see if they patch correctly or i've messed them. > > Btw, have you been able to try the > backend? > > > > > > They all apply cleanly but you have to hunt > around to find > > which directory to start in for each file. I'm going to combine them > into one > > patch that can be applied from the root directory. > > > > > > I haven't really looked at the backend yet . I > did notice > > that there was a pseudo instruction (spload) that made it into the > assembly > > file which stopped avr-gcc from being able to assemble it though. > > > > main: > > push r28 > > push r29 > > spload r29:r28, SP > > sbiw r29:r28, 2 > > ldi r24, 0 > > ldi r25, 0 > > std Y+1, r24 > > std Y+2, r25 > > spload r29:r28, SP > > adiw r29:r28, 2 > > pop r29 > > pop r28 > > ret > > > > > > > > > > > > |
|
From: Weddington, E. <Eri...@at...> - 2011-12-30 05:57:12
|
Hi Sherard, No, it's not a dead project. However, it is a slow-moving project. :-) There are some behind-the-scenes work going on by a couple of the developers. But this does not mean "behind close doors". It's usually sporadic work that is going on, that is not yet committed, usually due to developer time constraints. If I may ask, what is your interest in the project? Thanks, Eric Weddington > -----Original Message----- > From: Sherard Dames [mailto:sc...@gm...] > Sent: Thursday, December 29, 2011 12:14 PM > To: avr...@li... > Subject: [avr-llvm-devel] Current Status? > > Hello everyone, > > I'm curious as to the current status of this project. From the looks of > the SVN (and the mailing list) it would appear that the project is > fairly inactive. Is it simply that work is going on behind closed doors? > Or perhaps, is it a dead project? > > > > > ------------------------------------------------------------------------ -- > ---- > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > avr-llvm-devel mailing list > avr...@li... > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel |
|
From: Sherard D. <sc...@gm...> - 2011-12-31 00:11:24
|
Hi Eric, I am interested in an AVR backend for LLVM, so naturally I stumbled across this project. So I suppose my interest would be contribution as I have quite a bit of time on my hands, and would like to see it happen. I have been hacking away to get my hands dirty with LLVM, as I am unfamiliar with it. Ultimately I was hoping to contribute to a pre-existing effort, and I would like to get started here. I would appreciate some guidance as to some goals that I could begin helping around with, as I'm not sure about the status of the code in the SVN repository (or what's "safe" to work on). I'm very interested in getting this project moving a bit more. Thanks, On Thu, 2011-12-29 at 22:28 -0700, Weddington, Eric wrote: > Hi Sherard, > > No, it's not a dead project. However, it is a slow-moving project. :-) > > There are some behind-the-scenes work going on by a couple of the > developers. But this does not mean "behind close doors". It's usually > sporadic work that is going on, that is not yet committed, usually due > to developer time constraints. > > If I may ask, what is your interest in the project? > > Thanks, > Eric Weddington > > > -----Original Message----- > > From: Sherard Dames [mailto:sc...@gm...] > > Sent: Thursday, December 29, 2011 12:14 PM > > To: avr...@li... > > Subject: [avr-llvm-devel] Current Status? > > > > Hello everyone, > > > > I'm curious as to the current status of this project. From the looks > of > > the SVN (and the mailing list) it would appear that the project is > > fairly inactive. Is it simply that work is going on behind closed > doors? > > Or perhaps, is it a dead project? > > > > > > > > > > > ------------------------------------------------------------------------ > -- > > ---- > > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a > complex > > infrastructure or vast IT resources to deliver seamless, secure access > to > > virtual desktops. With this all-in-one solution, easily deploy virtual > > desktops for less than the cost of PCs and save 60% on VDI > infrastructure > > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > > _______________________________________________ > > avr-llvm-devel mailing list > > avr...@li... > > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel |
|
From: John M. <ato...@gm...> - 2012-01-02 07:46:16
|
Hi Sherard, Borja was working on a re-write of the llvm code. What's in llvm trunk now has a lot of bit-rot so spending too much time on it before the new code is committed would be a waste. Borja's mentioned we need more test cases to spot regressions. We have some test cases but they're not organized or in the format that the LLVM tools use.* So one helpful thing would be to create/document/organize test cases and then also make them work with the LLVM regression test system. * There's also plenty of work for the Clang and Dragonegg front ends. Dragonegg [http://dragonegg.llvm.org/] is the gcc front end. There will probable be a lot of people who will prefer to tryout LLVM through the more gradual transition via Dragonegg. I've added some skeleton files but basically nothing been done with Dragonegg. *So creating an AVR-Dragonegg port is needed.* *Building/testing an avr-gcc version that works with plugins (aka Dragonegg) also needs to be done.* I believe avr-gcc needs to be compiled to support LTO and plugins. *Getting the avr patches to apply cleanly to the current LLVM trunk probable is needed also.* This should be simple task. Thanks, John On Fri, Dec 30, 2011 at 4:11 PM, Sherard Dames <sc...@gm...> wrote: > Hi Eric, > > I am interested in an AVR backend for LLVM, so naturally I stumbled > across this project. So I suppose my interest would be contribution as I > have quite a bit of time on my hands, and would like to see it happen. > > I have been hacking away to get my hands dirty with LLVM, as I am > unfamiliar with it. Ultimately I was hoping to contribute to a > pre-existing effort, and I would like to get started here. > > I would appreciate some guidance as to some goals that I could begin > helping around with, as I'm not sure about the status of the code in the > SVN repository (or what's "safe" to work on). I'm very interested in > getting this project moving a bit more. > > Thanks, > > > > On Thu, 2011-12-29 at 22:28 -0700, Weddington, Eric wrote: > > Hi Sherard, > > > > No, it's not a dead project. However, it is a slow-moving project. :-) > > > > There are some behind-the-scenes work going on by a couple of the > > developers. But this does not mean "behind close doors". It's usually > > sporadic work that is going on, that is not yet committed, usually due > > to developer time constraints. > > > > If I may ask, what is your interest in the project? > > > > Thanks, > > Eric Weddington > > > > > -----Original Message----- > > > From: Sherard Dames [mailto:sc...@gm...] > > > Sent: Thursday, December 29, 2011 12:14 PM > > > To: avr...@li... > > > Subject: [avr-llvm-devel] Current Status? > > > > > > Hello everyone, > > > > > > I'm curious as to the current status of this project. From the looks > > of > > > the SVN (and the mailing list) it would appear that the project is > > > fairly inactive. Is it simply that work is going on behind closed > > doors? > > > Or perhaps, is it a dead project? > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > -- > > > ---- > > > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a > > complex > > > infrastructure or vast IT resources to deliver seamless, secure access > > to > > > virtual desktops. With this all-in-one solution, easily deploy virtual > > > desktops for less than the cost of PCs and save 60% on VDI > > infrastructure > > > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > > > _______________________________________________ > > > avr-llvm-devel mailing list > > > avr...@li... > > > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel > > > > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > avr-llvm-devel mailing list > avr...@li... > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel > |
|
From: Sherard D. <sc...@gm...> - 2012-01-04 04:06:06
|
John, I've looked into writing more test cases. It seems that the LLVM regression testing system is incredibly easy to use, and I've already mocked up a few tests with it. Are there any specific things I should have in mind when writing tests? Will soon take a look at bringing the patches up to date with the LLVM trunk. (I assume we're talking about those in the svn /llvm/trunk/patches/) As for DragonEgg, not sure I understand it. From what basic research I did on it, I didn't find a whole lot of documentation but from what I gathered so far I'm not sure I see the benefits. The most obvious benefit I could see was to leverage GCC's existing AVR support instead of patching clang. However to me that just seems like shifting effort from one place to another (clang to DragonEgg) to get (essentially) the same result. That idea aside, as far as I'm aware, clang already tries to be very compatible with GCC. Additionally Windows does not seem to be on that list of "successfully used on" platforms for DragonEgg, and I might be wrong about this, but I thought Windows was the most common development platform for the AVR? What is it that I'm missing here? Thanks, -----Original Message----- From: John Myers <ato...@gm...> To: Sherard Dames <sc...@gm...> Cc: avr...@li... Subject: Re: [avr-llvm-devel] Current Status? Date: Sun, 1 Jan 2012 23:46:08 -0800 Hi Sherard, Borja was working on a re-write of the llvm code. What's in llvm trunk now has a lot of bit-rot so spending too much time on it before the new code is committed would be a waste. Borja's mentioned we need more test cases to spot regressions. We have some test cases but they're not organized or in the format that the LLVM tools use. So one helpful thing would be to create/document/organize test cases and then also make them work with the LLVM regression test system. There's also plenty of work for the Clang and Dragonegg front ends. Dragonegg [http://dragonegg.llvm.org/] is the gcc front end. There will probable be a lot of people who will prefer to tryout LLVM through the more gradual transition via Dragonegg. I've added some skeleton files but basically nothing been done with Dragonegg. So creating an AVR-Dragonegg port is needed. Building/testing an avr-gcc version that works with plugins (aka Dragonegg) also needs to be done. I believe avr-gcc needs to be compiled to support LTO and plugins. Getting the avr patches to apply cleanly to the current LLVM trunk probable is needed also. This should be simple task. Thanks, John On Fri, Dec 30, 2011 at 4:11 PM, Sherard Dames <sc...@gm...> wrote: Hi Eric, I am interested in an AVR backend for LLVM, so naturally I stumbled across this project. So I suppose my interest would be contribution as I have quite a bit of time on my hands, and would like to see it happen. I have been hacking away to get my hands dirty with LLVM, as I am unfamiliar with it. Ultimately I was hoping to contribute to a pre-existing effort, and I would like to get started here. I would appreciate some guidance as to some goals that I could begin helping around with, as I'm not sure about the status of the code in the SVN repository (or what's "safe" to work on). I'm very interested in getting this project moving a bit more. Thanks, On Thu, 2011-12-29 at 22:28 -0700, Weddington, Eric wrote: > Hi Sherard, > > No, it's not a dead project. However, it is a slow-moving project. :-) > > There are some behind-the-scenes work going on by a couple of the > developers. But this does not mean "behind close doors". It's usually > sporadic work that is going on, that is not yet committed, usually due > to developer time constraints. > > If I may ask, what is your interest in the project? > > Thanks, > Eric Weddington > > > -----Original Message----- > > From: Sherard Dames [mailto:sc...@gm...] > > Sent: Thursday, December 29, 2011 12:14 PM > > To: avr...@li... > > Subject: [avr-llvm-devel] Current Status? > > > > Hello everyone, > > > > I'm curious as to the current status of this project. From the looks > of > > the SVN (and the mailing list) it would appear that the project is > > fairly inactive. Is it simply that work is going on behind closed > doors? > > Or perhaps, is it a dead project? > > > > > > > > > > > ------------------------------------------------------------------------ > -- > > ---- > > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a > complex > > infrastructure or vast IT resources to deliver seamless, secure access > to > > virtual desktops. With this all-in-one solution, easily deploy virtual > > desktops for less than the cost of PCs and save 60% on VDI > infrastructure > > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > > _______________________________________________ > > avr-llvm-devel mailing list > > avr...@li... > > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ avr-llvm-devel mailing list avr...@li... https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel |
|
From: John M. <ato...@gm...> - 2012-01-04 06:59:56
|
On Tue, Jan 3, 2012 at 8:05 PM, Sherard Dames <sc...@gm...> wrote: > John, > > I've looked into writing more test cases. It seems that the LLVM > regression testing system is incredibly easy to use, and I've already > mocked up a few tests with it. Are there any specific things I should > have in mind when writing tests? > > Borja would have a better idea of which tests are needed now. The MSP430 target (llvm/test/CodeGen/MSP430) may be helpful as an example. I think we'll basically need tests for each asm instruction to start with. Also test that show the avr-gcc ABI works properly (calls, returns, stack pointer...). Also thinks like auto, global, static, and volatile variables. > Will soon take a look at bringing the patches up to date with the LLVM > trunk. (I assume we're talking about those in the > svn /llvm/trunk/patches/) > > Yeah, and also the clang patches (cfe/trunk/patches). > As for DragonEgg, not sure I understand it. From what basic research I > did on it, I didn't find a whole lot of documentation but from what I > gathered so far I'm not sure I see the benefits. The most obvious > benefit I could see was to leverage GCC's existing AVR support instead > of patching clang. However to me that just seems like shifting effort > from one place to another (clang to DragonEgg) to get (essentially) the > same result. That idea aside, as far as I'm aware, clang already tries > to be very compatible with GCC. Additionally Windows does not seem to be > on that list of "successfully used on" platforms for DragonEgg, and I > might be wrong about this, but I thought Windows was the most common > development platform for the AVR? What is it that I'm missing here? > > Basically it allows people to use the avr-gcc compiler and still get the advantages of the llvm backend's code generation and optimization. Personally I would prefer working on only Clang. I have a feeling though we'll need DragonEgg to get people to transition over to CLANG/LLVM. I'm more then happy to be wrong though. There was (is?) an issue with windows dll's and the gcc plugin interface. I read that there was a fix in the works though. Yeah, Clang is designed to be a drop in replacement (minus a few purposeful exceptions) for gcc. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X