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
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
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>
On 25 September 2013 22:13, Preston Briggs <preston.briggs at gmail.com> wrote:> 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. >Another approach, a mix between a dummy back end and Karen's proposal, is to not only write documents on how things piece together, but also add comments to the code on how important this file/function is, how it fits with the rest, and how generic/specific it is. Documentations get outdated more often than comments in the code, and LLVM is particularly good at generic comments, but not so much at teaching how to use the code. Patches adding comments are also a good way to learn how something works. You send a comment, people say how wrong that is, and in the end, you learn by teaching others via your comments. cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130925/4aabd123/attachment.html>
Have you read through http://llvm.org/docs/CodeGenerator.html ? It's a reasonably good document, but IME people tend to ignore it. On Sep 25, 2013, at 2:13 PM, Preston Briggs <preston.briggs at gmail.com> wrote:> 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.SelectionDAG is actually not a BURG optimal tiler; it's a simple maximal munch pattern-matcher. The output of the instruction selector is still in SSA form, which mandates that, no matter the address form of your machine, you'll need to model operations as been three-operand, with a tying constraint that will be satisfied later by the register allocator. I don't know that anyone has been particularly successful at targeting accumulator architectures with LLVM, but you might look at how X86 handles integer multiplies for some inspiration.> what do we want to build? Do we need an assembler?, a disassembler?, a JIT?, an instruction scheduler?, a register allocator?The minimal amount of stuff you need to write is described in http://llvm.org/docs/WritingAnLLVMBackend.html#basic-steps Generally speaking, it amounts to defining your register classes and instructions, and implementing enough callbacks for instruction selection and register allocation (e.g., how to materialize a copy). --Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130926/900fb075/attachment.html>