Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Renato Golin <renato.golin <at> linaro.org>
Subject: Re: PIC Micropchip Backend
Newsgroups: gmane.comp.compilers.llvm.devel
Date: Monday 1st June 2015 08:41:32 UTC (over 2 years ago)
Hi Woodrow,

I have thought about introducing a PIC back-end just for fun, but
since there was one already dying, I gave up. It'd be great to have
one again, but we must not follow the steps of the previous back-end,
or the fate will be the same.

On 1 June 2015 at 05:55, Woodrow Barlow  wrote:
> Is there any development on this front currently?

Not that I'm aware of.


> Is there any interest in developing this for the current build of LLVM?

Interest in developing, probably not. Interest in having it, sure, why not!

However, a back-end maintainer has to provide a few "guarantees" to
continue supporting in tree:

1. You must have a public buildbot that can test your code. Since
you'll always cross compile, having a good set of tests in x86 mode
would do, but having execution tests would increase the quality by a
large amount. If at all possible, I'd recommend a cross-compilation
buildbot that runs some embedded code in a proper PIC.

2. Since this is an uncommon target, you'll need to be responsive to
bugs in your back-end. If one commit breaks your tests, we'll probably
revert until it can be fixed, but without PIC knowledge, it'll be hard
to fix the problem in your back-end. Lack of execution tests, as
mentioned above, will increase the uncertainty.

3. You should follow the high level discussions about DAG lowering,
register allocation, etc., as any of that might change how your
back-end behaves. Breaking your back-end by changing any of those
high-level parts of the code is reasonably common. You can be either
proactive, and help us make those changes on your back-end, or
reactive as point (2) above, and fix promptly any bug that shows up.


> Why was the original support dropped?

Because the previous maintainer didn't follow the rules above. :)

Any part of the code that bit rots (remains untouched for a long time
with no one responsible for it) will be discarded.

This is kind of a life contract, too. You or someone else will have to
keep an eye on the back-end for as long as LLVM lives, or as long as
you care about a PIC back-end in LLVM.

It's like reference counted smart pointers... The last one to leave,
turn the lights off.


> Would it make a good basis for current support, or
> has the core software changed too much since then?

The core has changed drastically, but some of the basics of building a
back-end are still the same.

There is plenty of documentation available to help you with that. Some
examples:

http://llvm.org/docs/WritingAnLLVMBackend.html
http://llvm.org/devmtg/2014-04/PDFs/Talks/Building%20an%20LLVM%20backend.pdf
http://llvm.org/devmtg/2014-10/Slides/Cormack-BuildingAnLLVMBackend.pdf
(same, but newer)
http://jonathan2251.github.io/lbd/

But digging the old code and looking at the patterns would probably
help you to get started. Also, check the other back-ends for
implementing common patterns, and try to leave as much as you can to
the generic parts of the code.

cheers,
--renato

PS: I may know a few people that would be interested in helping... Let
me ask around.
 
CD: 3ms