[LLVMdev] PIC16 removal details

[Matthew Hilt]

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>