[LLVMdev] llvm backend

[Jim Grosbach]

On May 11, 2011, at 11:50 AM, Roberto Rodríguez-Rodríguez wrote:

> 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 files that the compiling process did are: 
> 
> llvm-2.8/Release/lib/libLLVMMSP430Info.a
> llvm-2.8/Release/lib/libLLVMMSP430AsmPrinter.a
> llvm-2.8/Release/lib/libLLVMMSP430CodeGen.a
> 
> and none of them work.
> 
> is It possible to load a backend as a new pass, for practicing I have worked on create passes like deadcode analysis and it is possible to load them with opt, but I don't know how to generate code for my new backend. Thank you.
> 

A new backend is not equivalent to a new pass and cannot be loaded dynamically like that. It's a wholly different construct.

I would highly recommend looking at the SVN history of the MSP430 backend as it was added. Some things have changed since then, but you'll still be able to get the general idea for what needs to happen in the Makefiles, Triple definitions and such to get the infrastructure up and running.

-Jim


> 
> 
> 2011/5/10 Jim Grosbach <grosbach at apple.com>
> 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 and running relatively quickly. When you run into things you need to model that aren't represented in your reference backend, then it's time to look at others to see if there's something similar there.
> 
> Your biggest challenges on the PIC24 will be with regards to program memory data pointers. The ISA level Harvard architecture stuff isn't handled by LLVM very well at the moment. Address spaces get you part of the way there, but not completely. You may be able to work around that, depending on how much memory your devices have, by using the 32k window that maps program memory into data memory. Similarly, program memory pointers and data memory pointers aren't the same size, and LLVM isn't fond of that notion. It wants all pointers to be the same size. You could use a super-set pointer size that's big enough for either, but that results in each pointer taking two registers, whether it needs to or not, which is pretty much a deal-breaker as it would make for horrible code size and performance, both. More likely you'll want to go the other way and have universal 16-bit pointers and deal with the upper bits of program memory addresses with attributes and some kind of back-end cooperation with the linker. For additional "fun", have a look at the Microchip port of binutils with regards to the so-called "phantom byte" in program memory.
> 
> Getting a basic, mostly functional port for the PIC24 should be relatively straightforward. Its instruction set is well suited for compilers. Filling in around the edges to make it a full-featured production quality compiler, on the other hand, will be quite the challenge. The rough edges on the architecture are very rough indeed from a compiler's perspective.
> 
> Microchip supplies a port of GCC for the architecture which, while somewhat dated, is robust and well maintained. Even if the compiler itself isn't suitable for your needs, I would highly recommend having a look at it, both the documentation and the source code, for more in depth background. The source code should be available on Microchip's web site. If you have any trouble locating it, or just have some questions about the architecture, compiler, or what-have-you, contacting the Microchip compiler team would be a good way to go. They're good folks.
> 
> Regards,
> -Jim
> 
> On May 10, 2011, at 7:08 AM, Roberto Rodríguez-Rodríguez wrote:
> 
>> 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 MIPS but the problem is the same, all the documention said what the files have to contain but not the details about write them.
>> 
>> I need to write a backend for the PIC24, our processor is based on it, so I started analyzing the files for the implementation of the PIC16, all was ok until I analyzed the files PIC16ILowering.cpp and PICInstrInfo.td, this files have defined many things like SDTypeProfile and SDNode and other things I don't have idea from where they come. I mean I tried to find this info from other files, llvm.org and google and no idea. 
>> 
>> I have checked the documentation, after read it I thought the implementation will be a not to difficult job, but analyzing the files I realized I didn't have idea about the magnitude of the problem. 
>> 
>> Any suggestion will be appreciated. 
>> 
>> Best Regards
>>              Roberto
>> 
>> 
>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev