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 I can get some details as to why it was dropped firstly and also, why would it be 'largely a rewrite' if it were resumed? Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110921/afdb698c/attachment.html>
On Tue, Sep 20, 2011 at 10:59 PM, Matthew Hilt <mhilt1 at gmail.com> 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 will be largely a rewrite". > > I'm wondering if I can get some details as to why it was dropped firstly and > also, why would it be 'largely a rewrite' if it were resumed? Thanks in > advance.It was incomplete and unmaintained for a long time. Regarding the largely rewrite, I suppose it's because the type support for several operations would have to be implemented better in target independent code. -- Bruno Cardoso Lopes http://www.brunocardoso.cc
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 will be largely a rewrite". > > I'm wondering if I can get some details as to why it was dropped firstly and also, why would it be 'largely a rewrite' if it were resumed? Thanks in advance.LLVM is designed for "normal" architectures. The further from approximately the intersection of x86 and ARM, the more it takes to use LLVM effectively. PIC16, we learned, is well out there, from LLVM's perspective. As one example, LLVM is built to optimize for machines with numerous general-purpose registers. It's a stretch to even say that PIC16 has a single general-purpose register. The PIC16 backend developers asked for ways to prevent LLVM from promoting variables from memory into registers, because it was pessimizing code for PIC16. However, LLVM can't do that without also shutting down large parts of itself, because of the pervasive assumption that registers are where the action is. Dan
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 new releases however, and that were it to be resumed "it will be largely a rewrite". >> >> I'm wondering if I can get some details as to why it was dropped firstly and also, why would it be 'largely a rewrite' if it were resumed? Thanks in advance. > > LLVM is designed for "normal" architectures. The further from > approximately the intersection of x86 and ARM, the more it takes to > use LLVM effectively. PIC16, we learned, is well out there, from > LLVM's perspective.An eight-bit, accumulator based, Harvard ISA is the Trifecta of Doom as far as LLVM is concerned, basically.> As one example, LLVM is built to optimize for machines with numerous > general-purpose registers. It's a stretch to even say that PIC16 has > a single general-purpose register. The PIC16 backend developers > asked for ways to prevent LLVM from promoting variables from memory > into registers, because it was pessimizing code for PIC16. However, > LLVM can't do that without also shutting down large parts of itself, > because of the pervasive assumption that registers are where the > action is.To be fair, I don't think that was a good approach to that problem. Neither here nor there at this point, though. -Jim