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
The target in this case is 8-bit, accumulator based, however it is Von Neumann; so - good to know it's not *quite* the "Trifecta of Doom". LLVM offers some very attractive features for our usage, and it would be disappointing to abandon it as an option all together. Faced with the alternative being to write the compiler from scratch, is the consensus that doing so will be a better path forward for us than a new LLVM backend? Matt On Wed, Sep 21, 2011 at 6:05 PM, Jim Grosbach <grosbach at apple.com> wrote:> > 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110921/06dde492/attachment.html>
On Sep 21, 2011, at 4:51 PM, Matthew Hilt wrote:> The target in this case is 8-bit, accumulator based, however it is Von Neumann; so - good to know it's not *quite* the "Trifecta of Doom". LLVM offers some very attractive features for our usage, and it would be disappointing to abandon it as an option all together. Faced with the alternative being to write the compiler from scratch, is the consensus that doing so will be a better path forward for us than a new LLVM backend?It's hard to say. To most of us, "8-bit accumulator based" suggests a heavy load of constraints. The more constraints you have, the harder it's going to be to shoehorn a large, complex, and naive (to your constraints) piece of software into the middle of everything, interposed between the programmer and the hardware. It will require more than just extending LLVM to your needs. It'll require fighting against LLVM actively working against your needs. Dan