llvm backend

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

llvm backend

Roberto Rodríguez-Rodríguez
Hi,

I am writing you because I found in the LLVM site you have worked with backends. I am writing a new backend for a processor I am working on, because the compiler that comes with the processor design suite is really messy (it is CoSy). I want to have a power compiler like llvm.

I read the "writing an LLVM compiler backend" and I have define almost all the files, but I have problems with the files for the instructions set. XXXInstrInfo.td is giving a headache, I have not found enough information about all the things I have to define hear. I also tried program by example and see the files for the PIC16, Sparc and MIPS but they are so different as to get a pattern.

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.

Greetings
             Roberto




_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: llvm backend

Anton Korobeynikov-2
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 ago, so some API already changed...

http://www.llvm.org/devmtg/2009-10/Korobeynikov_BackendTutorial.pdf
might help as well.

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: llvm backend

Roberto Rodríguez-Rodríguez
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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: llvm backend

Jim Grosbach
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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: llvm backend

Roberto Rodríguez-Rodríguez
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 <[hidden email]>
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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]>
> 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
>> [hidden email]         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: llvm backend

Sanjiv Gupta
In reply to this post by Jim Grosbach


2011/5/10 Jim Grosbach <[hidden email]>
Hi Roberto,

That said, that does mean that LLVM is a much more reasonable fit to target the PIC24 (and dsPIC) than it is for PIC16.




Hi Roberto,
PIC16 was full of challenges and we had to do very unconventional things to get it generate PIC16 code. One of the most difficult thing was that we wanted 16-bit pointers which is an 'illegal' type size on the target. There were so many more things other than that.  You may find some of the discussions in the archives.

Having said that, PIC24 and PIC16 are entirely different and PIC24 might be more suited for LLVM port.

- sanjiv




_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev