[LLVMdev] request for tutorial

[Preston Briggs]

Thanks all, for all the pointers. I'd read some of them, but others are new.
Jim, I'd certainly appreciate the chance to get together at the dev
conference.
I think y'all's ideas of a stub back end sound good, though I can
appreciate the maintenance difficulties.
Karen's idea for a new design guide is also good, though I think the idea
of looking at other back ends for examples of good design is perhaps wrong.

 A lot of my difficulty in reading other examples is that it's not clear
what matters and what doesn't. It's what I hope to get by sitting next to
someone and asking questions. Some of this could be addressed in a guide.
I'd start with a chapter on planning. When writing a new back end, we
wonder:

   - what sort of architecture are we dealing with? 3-address, 2-address,
   1-address, 0-address (stack machine)?
   - what do we want to build? Do we need an assembler?, a disassembler?, a
   JIT?, an instruction scheduler?, a register allocator?
   - Can we talk about all these things in an orthogonal fashion? With
   examples, or perhaps pointer to specific targets that illustrate different
   things?
   -

I don't really find it in the documentation so far, but I think the
instruction selection stuff is based on a BURG-like pattern matcher. It
seems like this is the key intellectual challenge for the not-completely
RISC machines. Lots of discussion seems warranted, but I find none at all.
Somewhere inside the x86 target must be a lot of stuff on how to handle a
2-address machine. I've done an x86 CG once before, and all of the fun was
in getting the right set of patterns to handle the fancy addressing modes,
the condition codes, and the 2-address instructions. I'm working on a
1-address machine now (an accumulator machine, with a set of register and
an accumulator, and instructions of the form ACC += Register) and the
pattern matcher to do everything optimally is delightful.

I have an assembler, don't care about scheduling (except to reduce register
pressure, so a variant of SU-numbering will do), don't need a JIT, don't
have any subtargets, so many things can be ignored. I expect others will
have similar problems, in that they only need a subset of the capabilities.

Thanks,
Preston



On Wed, Sep 25, 2013 at 11:20 AM, Rafael Espíndola <
rafael.espindola at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130925/876df586/attachment.html>