On 24 Sep 2013, at 22:14, Anton Korobeynikov <anton at korobeynikov.info> wrote:> The backend stub is available at https://github.com/asl/llvm-openrisc > but given the LLVM development speed it's heavily outdated. Maybe it > will make sense to look into new backends like SystemZ.It would be nice if a stub backend could be committed to the tree and so it would stay up to date with changes... David
On 25 September 2013 08:48, David Chisnall <David.Chisnall at cl.cam.ac.uk>wrote:> It would be nice if a stub backend could be committed to the tree and so > it would stay up to date with changes... >That is a good idea. The caveat is that people needing quick changes to their backends (for fixing buildbots, for instance) would have the chance to break the dummy back-end and slow down bug-fixing, or end up disabling some tests on the dummy backend just to fix the problem. I can't predict how much of it will actually impact day-to-day development, but it'd be crucial to have some code owner that would keep it tidy and relevant. Anton, I've forked your repository in GitHub and I'll give it a try to make it work on the new LLVM, but if you have some time, feel free to do it, too. ;) cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130925/aa0e27f0/attachment.html>
> It would be nice if a stub backend could be committed to the tree and so it would stay up to date with changes...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... -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
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 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/a1ee0624/attachment.html>