[LLVMdev] request for tutorial

[Sean Silva]

On Wed, Sep 25, 2013 at 7:02 AM, Renato Golin <renato.golin at linaro.org>wrote:

> On 25 September 2013 11:50, Anton Korobeynikov <anton at korobeynikov.info>wrote:
>
>> I asked for this several times and the conclusion was "no, what for,
>>  we have plenty of other backends in the tree which can be thought as
>> examples". IMHO, it will be nice thing to have though...
>>
>
> I think that it would be fine as long as we have two conditions:
>  * Fixes on other back-ends that break the dummy tests are allowed to
> disable them
>  * Code owners will fix the broken tests on a timely basis
>

(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.

Just as having a reduced testcase is much easier to debug compared to the
original unreduced code it originates from, so too a stub backend could be
useful to gain understanding of what is happening in a real backend.

If we included a script that duplicates the stub into a new directory and
renames things appropriately (and probably also clang-format's it along the
way, since name lengths may have changed), that would radically alter how
easy it is to teach/learn about the backends too, for example, with a "real
backend", it's just not going to be realistic to have a learning material
like the following:
    1. Explain calling convention handling, and how XXXCallingConv.td works
    2. Have an exercise "implement a calling conv with these properties:
..."
... since with a real backend, you don't want to be messing around and
inserting random new calling conventions/instructions/etc., but with a stub
(or even better, a clone of the stub), it is natural to say "suppose that
the target were different in this
entirely-hypothetical-but-pedagogically-useful respect; modify the code to
handle this". Those kinds of hands-on exercises are fundamental to gaining
confidence with how code works.

So I think the argument can be made that even though a stub backend might
represent an additional maintenance burden, what you get in return is that
it becomes a lot easier to attract developers to work on the backend
(either existing LLVM developers that didn't do backend stuff, or new
contributors), which then share the maintenance burden. Realistically, even
if the stub backend contributes to attracting just *1* new contributor to
backend development, who goes on to work full-time on LLVM, then it will
have paid for itself many times over in maintenance cost.

-- Sean Silva


>
> If most/all tests end up disabled because they all break, then it'd be
> good to remove from the tree, since the code owners are not doing their job
> right.
>
> Would also be good to get bugs created for each test other people disable,
> so we could prioritize the changes.
>
> I don't know much about that back-end, but I'd really wanted to learn
> building one from scratch, so I could help you on the bug-fixing and adding
> lots of comments to help guide folks through the changes, but I can't be
> the sole owner, as I know nothing about it. ;)
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130925/d4906125/attachment.html>