<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 25, 2013 at 7:02 AM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="im">On 25 September 2013 11:50, Anton Korobeynikov <span dir="ltr"><<a href="mailto:anton@korobeynikov.info" target="_blank">anton@korobeynikov.info</a>></span> wrote:<br>
<div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><span style="color:rgb(34,34,34)">I asked for this several times and the conclusion was "no, what for,</span><br>

</div>
we have plenty of other backends in the tree which can be thought as<br>
examples". IMHO, it will be nice thing to have though...<br></blockquote><div></div></div><br></div></div><div class="gmail_extra">I think that it would be fine as long as we have two conditions:</div><div class="gmail_extra">

 * Fixes on other back-ends that break the dummy tests are allowed to disable them</div><div class="gmail_extra"> * Code owners will fix the broken tests on a timely basis</div></div></blockquote><div><br></div><div>(Devil's advocate, but half serious):</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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:</div>
<div>    1. Explain calling convention handling, and how XXXCallingConv.td works</div><div>    2. Have an exercise "implement a calling conv with these properties: ..."</div><div>... 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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra">

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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">

Would also be good to get bugs created for each test other people disable, so we could prioritize the changes.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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. ;)</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">cheers,</div><div class="gmail_extra">--renato</div></div>
</blockquote></div><br></div></div>