similar to: [LLVMdev] llvm backend

I have been analyzing the implementation for some backend (PIC16, MIPS, SPARC and MSP430) my main problem is that they are so much different, I mean obviously they are describing different architectures, but the file structure is not the same. So it is difficult to get a pattern. I have checked the available documentation files, also the video from Cardoso about how to write a backend for the

Hello Roberto, > Do you have any information I can use for define my new backend? I really > appreciate your attention and any help you can give me. You might want to look into some of the existing backends. Probably MSP430 is the smallest one. Try to examine the history how this backend was added, it was preserved specifically for educational purposes. I must note that it was added 2 years

Hi Roberto, The PIC24 family of devices share very little commonality with PIC16 beyond the naming convention. They're a register-based 16-bit architecture, unlike the PIC16. That said, that does mean that LLVM is a much more reasonable fit to target the PIC24 (and dsPIC) than it is for PIC16. Modeling your target files after the MSP430 or Blackfin backend is likely your best bet to get up

Hi, I think this is a very ashamed question I have modified the version of the MSP430, after many problems it compiled, now I want to see is the changes generate what I want, but I don't know how for example with llc -march msp430 foo.ll -o newfoo.ll generates a file for the msp430 and actually did it. but I want to load my changes the --load option is supposed to do that, but the only new

Hi all, I started to write an LLVM backend for custom CPU. I created XXXInstrInfo but there are some problems. I searched for it but I couldn't find anything. Can anyone help me? include "XXXInstrFormats.td" def simm16 : Operand<i32> { let DecoderMethod = "DecodeSimm16"; } def mem : Operand<i32> { let PrintMethod = "printMemOperand"; let

llvm no build? llvm/llvm/lib/Target/PIC16/PIC16AsmPrinter.cpp: In member function ‘bool llvm::PIC16AsmPrinter::printMachineInstruction(const llvm::MachineInstr*)’: llvm/lib/Target/PIC16/PIC16AsmPrinter.cpp:80: error: ‘CurBank’ was not declared in this scope llvm/lib/Target/PIC16/PIC16AsmPrinter.cpp: In member function ‘virtual bool llvm::PIC16AsmPrinter::runOnMachineFunction

I've been looking closely at LLVM as a means to developing a new toolchain for an MCU core of very similar architecture. To that end, the once included PIC16 backend might be a valuable reference. I found a message in April of this year that indicated it had been dropped from new releases however, and that were it to be resumed "it will be largely a rewrite". I'm wondering if

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

On Sep 20, 2011, at 10:59 PM, Matthew Hilt wrote: > I've been looking closely at LLVM as a means to developing a new toolchain for an MCU core of very similar architecture. To that end, the once included PIC16 backend might be a valuable reference. I found a message in April of this year that indicated it had been dropped from new releases however, and that were it to be resumed "it

Mike Stump wrote: > llvm no build? > > llvm/llvm/lib/Target/PIC16/PIC16AsmPrinter.cpp: In member function > ‘bool llvm::PIC16AsmPrinter::printMachineInstruction(const > llvm::MachineInstr*)’: > llvm/lib/Target/PIC16/PIC16AsmPrinter.cpp:80: error: ‘CurBank’ was not > declared in this scope > llvm/lib/Target/PIC16/PIC16AsmPrinter.cpp: In member function ‘virtual >

In -help output, -help - Display available options (--help-hidden for more) Both single and double - option markers are accepted, which is good. It would probably be better to refer to options consistently using the single marker in all cases. =linearscan - linear scan register allocator =pbqp - PBQP

On Sep 21, 2011, at 2:53 PM, Dan Gohman wrote: > On Sep 20, 2011, at 10:59 PM, Matthew Hilt wrote: > >> I've been looking closely at LLVM as a means to developing a new toolchain for an MCU core of very similar architecture. To that end, the once included PIC16 backend might be a valuable reference. I found a message in April of this year that indicated it had been dropped from

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

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

There is a ~/llvm-2.8/lib/Target/PIC16/ backend in llvm-2.8. It doesn't appear to be present in llvm-2.9. Has that backend been dropped? Graham

Mikhail Glushenkov wrote: > Hi Sanjiv, > > 2009/6/29 Sanjiv Gupta <sanjiv.gupta at microchip.com>: > >> I want to retrieve the value of argv[0] (which was passed to main function >> of the driver) in PrependCustomizedPath. >> > > I've added a way to access argv[0] in hooks: > http://thread.gmane.org/gmane.comp.compilers.llvm.cvs/50789 >

Hi Sanjiv, 2009/6/30 Sanjiv Gupta <sanjiv.gupta at microchip.com>: > One more thing: > How to make --save-temps always on, so that users won't have to specify it > every time they invoke the driver? Either always run the driver via an alias, or edit lib/CompilerDriver/BuiltinOptions.cpp: cl::opt<SaveTempsEnum::Values> SaveTemps ("save-temps",

When I registered for dev conference, there was a field asking what I was particularly interested in learning. I didn't fill it out then , but it occurs to me now that I'd really enjoy a tutorial on how to develop a new back end. I spent some time recently reviewing existing material (documentation and code) and not making a lot of progress. Indeed, under some time pressure, I'm

The driver behaves differently when I run it by specifying absolute path than when I run it with relative path. See example Relative: i00202 at ubuntu:/tmp$ mcc16 --save-temps -dry-run hello.c./clang-cc -I ./include -triple=pic16- -emit-llvm-bc hello.c -o hello.bc-pqDR1Y llvm-ld -link-as-library hello.bc-pqDR1Y -o tmp.bc-M1Rwip llc -march=pic16 -f tmp.bc-M1Rwip -o tmp.s-DcVczP gpasm -I ./inc

Does LLVM support any target platforms on which the natural integer size/pointer size is smaller than 32 bits? For example, I noticed mention of PIC16, is that such a platform? If so, does the usual rule about the largest supported integer being the size of two pointers still apply? So that on that platform you can't use 64-bit integers, but you can use 32-bit integers?