similar to: [LLVMdev] PIC16 asmprinter

Chris, I will try to get it done before 2.6. (8/21). - Sanjiv -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu on behalf of Chris Lattner Sent: Wed 8/12/2009 10:08 PM To: LLVM Developers Mailing List Subject: [LLVMdev] XCore & PIC16 AsmPrinters Hi XCore and PIC16 maintainers, I'd appreciate it if you guys could move your AsmPrinter implementation to be in a

Hi XCore and PIC16 maintainers, I'd appreciate it if you guys could move your AsmPrinter implementation to be in a subdirectory like the rest of the other targets (e.g. make it live in lib/Target/PIC16/AsmPrinter). Anton is planning to move MSP430 to use the same approach. Having all the targets use the same design simplifies the build system and keeps the target architecture more

> Chris Lattner wrote: > >> Hi XCore and PIC16 maintainers, >> >> I'd appreciate it if you guys could move your AsmPrinter >> implementation to be in a subdirectory like the rest of the other >> targets (e.g. make it live in lib/Target/PIC16/AsmPrinter). >> I've moved the XCore AsmPrinter in r79094:

Chris Lattner wrote: > Hi XCore and PIC16 maintainers, > > I'd appreciate it if you guys could move your AsmPrinter > implementation to be in a subdirectory like the rest of the other > targets (e.g. make it live in lib/Target/PIC16/AsmPrinter). > Hi Chris, I'll try to get this done either this weekend or early next week. -- Richard Osborne | XMOS

Chris Lattner wrote: > > On Aug 12, 2009, at 9:48 PM, Sanjiv.Gupta at microchip.com wrote: > >> Chris, >> I will try to get it done before 2.6. (8/21). >> > > Thanks Sanjiv! One other nice cleanup (but which is not time critical > at all) would be to merge the contents of "PIC16Section" into the new > "MCSectionPIC16" class. Unlike the

On Aug 12, 2009, at 9:48 PM, Sanjiv.Gupta at microchip.com wrote: > Chris, > I will try to get it done before 2.6. (8/21). > Thanks Sanjiv! One other nice cleanup (but which is not time critical at all) would be to merge the contents of "PIC16Section" into the new "MCSectionPIC16" class. Unlike the previous design, you're now allowed to store arbitrary

Extended thanks to the llvm community for feedback in advance, and especially thanks to Jim for laying out a solution that captures all aspects of the problems that we are facing. After some discussions with our team, we have decided to do the following, but to avoid further conflict with llvm standards, I would like to get the blessing of llvm community, and in particular, Chris who at some point

On Jul 20, 2009, at 4:18 PM, Alireza.Moshtaghi at microchip.com wrote: > Substituting the uses of a global with an absolute address would make > all accesses to that global through pointer, which is very inefficient > on PIC16. So we don't change the code generation for that global; > instead we only pass the address information to the linker (home made > linker) through some

On Aug 27, 2009, at 7:44 PM, Sanjiv Gupta wrote: > Chris Lattner wrote: >> >>> We provide two sets of intrinsic functions in the port >>> specific library and appropriate function call will be generated >>> depending on whether we are in ISR or mainline code. The right way >>> of >>> doing this is to keep all the logic in legalizer - use the

Chris Lattner wrote: > >> We provide two sets of intrinsic functions in the port >> specific library and appropriate function call will be generated >> depending on whether we are in ISR or mainline code. The right way of >> doing this is to keep all the logic in legalizer - use the existing >> infrastructure and customize the library calls for each non-native

Chris Lattner wrote: > In my ongoing work on refactoring the asmprinters, I've found that > PIC16 doesn't put ':' after labels in some cases. Specifically, it > looks like basic block labels are emitted without a ':': > > movwf @__floatunsidf.frame. + 2 > movlp .BB1_2 > goto .BB1_2 > .BB1_2

> My short term goal is to make TargetAsmInfo not depend on libvmcore. > This means that no methods in it should take GlobalValue*'s for > example. There is a suite of GV classification methods that need to > be moved somewhere else, probably in TargetLowering or asmprinter. One > method in particular (SectionForGlobal) is virtual and only re- > implemented for

I found out the problem. Looks like I can not rely on argv[0] to contain the full path of the executable always. Can I rely on: static Path GetMainExecutable(const char *argv0, void *MainAddr); is it Cross-platform? What to pass for second parameter here. C++ forbids taking address of "main", and the "Main" of CompilerDriver is in a shared object here. - Sanjiv Sanjiv

Well, the first email is here. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081013/068667.html -----Original Message----- From: Duncan Sands [mailto:baldrick at free.fr] Sent: Thu 1/8/2009 8:41 PM To: Sanjiv Kumar Gupta - I00171 Cc: llvmdev at cs.uiuc.edu Subject: Re: PIC16 backend for llvm 2.5 Hi Sanjiv, > We are targetting a reasonably functional PIC16 backend for llvm

> -----Original Message----- > From: Duncan Sands [mailto:baldrick at free.fr] > Sent: Friday, January 09, 2009 5:23 PM > To: Sanjiv Kumar Gupta - I00171 > Cc: llvmdev at cs.uiuc.edu > Subject: Re: PIC16 backend for llvm 2.5 > > Hi Sanjiv, > > > Well, the first email is here. > > > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon- >

Chris Lattner wrote: > > On Aug 21, 2009, at 11:13 AM, Alireza.Moshtaghi at microchip.com wrote: > >>>> Add a pass to do call graph analyis to overlay the autos and frame >>>> sections of >>>> leaf functions. This pass will be extended to color other nodes of >>>> the call tree >>>> as well in future. >>> >>>

Bringing it up again. - Sanjiv Sanjiv Gupta wrote: > Chris Lattner wrote: > >> We should discuss this on llvmdev, I think it came up before but there >> was no conclusive plan that was proposed. >> > The approach that we thought for PIC16 can be described in a > single line as below. > > "Keep the functions called from ISR and main separate by

Jim Grosbach wrote: > Hi Ali, > > Thanks for bringing this up. You're definitely under very tight design > constraints from the hardware. I can certainly sympathize. Jim, First of all, thank you very much for understanding every detail of the problem at our hand and coming up with a solution that addresses every aspect of it. IMO, given the constraints, this is probably the best

In my ongoing work on refactoring the asmprinters, I've found that PIC16 doesn't put ':' after labels in some cases. Specifically, it looks like basic block labels are emitted without a ':': movwf @__floatunsidf.frame. + 2 movlp .BB1_2 goto .BB1_2 .BB1_2 ; %bb7 movlw 0 banksel @__floatunsidf.frame. but that

Hi Sanjiv, Sanjiv Gupta <sanjiv.gupta <at> microchip.com> writes: > > PIC16 now has clang and llc based system to generate native assembly. We > then use our native assembler (gpasm) and the native linker (mplink) to > generate the final executable. How can I integrate these things with > the driver llvmc to have gcc like user experience? Note that we also >