[LLVMdev] request for tutorial

[Karen Shaeffer]

On Wed, Sep 25, 2013 at 02:20:18PM -0400, Rafael Espíndola wrote:
> On 25 September 2013 12:28, Sean Silva <chisophugis at gmail.com> wrote:
> >
> >
> >
> > On Wed, Sep 25, 2013 at 7:02 AM, Renato Golin <renato.golin at linaro.org>
> > wrote:
> >>
> > (Devil's advocate, but half serious):
> >
> > It may be a good idea to require that the dummy backend is kept up to date,
> > as a way to keep a pulse on changes to the interfaces between the
> > target-independent and target-dependent parts of LLVM. A slightly idealized
> > way to put it is that the dummy backend would be a "living definition" of
> > the boundary between the target-dependent and target-independent parts of
> > LLVM. By virtue of being just a stub, complexity related to being a "real
> > backend" could be removed, so that when you look at a file inside the stub
> > backend, you know that there isn't extraneous junk that some other target
> > wouldn't have: everything there is essentially an example of something that
> > every target has in common.
> >
> 
> These things have a tendency to bitrot. When I started looking at gcc
> it had an example frontend (treelang). The problem was that it was
> updated just enough to keep it building. It didn't follow the best
> practices that the other frontends had been moved too. In the end it
> was easier to read the fortran FE code than treelang's.
> 
> Cheers,
> Rafael
--- end quoted text ---

Hi,
Based on my experience, the best path forward is for folks to use the real
backends as examples of design. What is needed is a tightly focused backend design
guide available and properly maintained. The design guide should only touch on
the essential issues and concepts to help someone get started. The aspiring
backend designer must take responsibility for traversing the learning curve.
And in this context, one can envision the limited nature of the documented
design guide, where the goal is to point folks into the key objects in the
code with overview commentary concerning major dependencies, etc. Within
this limited scope, it shouldn't be too much of a burden to maintain the
design guide document, while providing motivated developers the bridge they
need to get started without wasting a lot of time.

enjoy,
Karen
-- 
Karen Shaeffer                 Be aware: If you see an obstacle in your path,
Neuralscape Services           that obstacle is your path.        Zen proverb