[LLVMdev] PIC16 removal details
Matthew Hilt
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.
Bruno Cardoso Lopes
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
_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Dan Gohman
> 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
Jim Grosbach
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
Matthew Hilt
Matt
Dan Gohman
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
Jim Grosbach
On Sep 26, 2011, at 11:29 AM, Dan Gohman wrote:
>
> 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.
Von Neumann is the biggest thing, so that's a good thing.
The PIC16 port chose to not use the mem2reg and reg2mem passes in the backend, which resulted in many of LLVM's optimization passes being severely hamstrung, not least because LLVM IR is SSA only for register values, not memory values. I would suggest instead investing the effort to implement target-specific code, both in instruction selection and in dedicated machine level passes, to optimize for the odder characteristics of this target. This would be immensely helped if you can fashion a good abstraction for what LLVM considers to be registers, perhaps onto a fast-access memory bank or something similar. The more you can do that, the more you'll be leveraging the existing codebase. A late machine function pass should be able to go through the code and clean up redundant copies, loads and stores. For example, the PIC16 could handle banking by having every global access include setting the bank bits, then have the appropriate target hooks to let the machine dead code elimina!
tion pass remove any extras, or, alternatively, insert no banking instructions at all and require the linker to insert them where required after data memory has been laid out (more work, but a superior end result).
Personally, I would consider whether that abstraction of LLVM's concept of registers could be found to be the go vs. no-go for a port. If I had a solution for that which wasn't a force-fit, then I'd give a true LLVM port a try. Otherwise, I'd lean towards alternatives. That said, I've written compilers for these sorts of architectures, and there's no easy answers no matter which way you go.
One middle ground alternative you may want to consider is using clang, but not the LLVM back end. One could theoretically hook up a lowering from clang's AST's that's not LLVM IR and feed that into a custom target-specific back end. That way you'd at least have all the awesome parsing and semantic analysis tools clang offers.
-Jim