[LLVMdev] llvm backend

Roberto Rodríguez-Rodríguez robalrr at gmail.com
Wed May 11 11:50:07 PDT 2011


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.

Best Regards
             Roberto



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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110511/561ec712/attachment.html>


More information about the llvm-dev mailing list