[llvm-dev] RFC: A mock backend target for LLVM

Tue Nov 19 00:24:44 PST 2019

There has been two rounds of discussion on the mailing list this year in relation to addressing the assumptions LLVM makes in relation to the size of  bytes, addressable unit sizes and use of magic numbers[1][2]. There has been consensus on moving forward but the stumbling block is testing.

[1] https://lists.llvm.org/pipermail/llvm-dev/2019-May/132080.html
[2] http://lists.llvm.org/pipermail/llvm-dev/2019-October/136115.html

The community is wary about accepting changes that break current assumptions without in tree testing. While I agree with this wholeheartedly  we have  kind of ended up in a catch-22 situation.  It is hard to move forward on this issue without an in tree target, but  none of those needing the changes upstream (myself included) can contribute their downstream backend to the upstream codebase.

The obvious solution is to have an in-tree mock backend target to test against.

A mock target does not have to be a working backend. It just has to appear to be a working backend to the LLVM testing infrastructure.

At this stage I'm not clear in my head what this would actually entail or if it can be done using the current infrastructure.  Would a mock need a very basic ISA for example? Would it be ok for some tests for a mock target not to have register classes or instructions defined? Can we just register components of a mock backend within the LLVM framework just for testing purposes.  Regardless I do think that a flexible solution  to implement testable changes that does not rely on a full backend implementation would be useful to the overall project.

I think a mock target that is a better idea than contributing a backend for an old architecture that may have some nonstandard  features just for testing.  Its only solution I can see that could help address the needs and concerns of both upstream and downstream users in relation to the size of bytes, chars and minimal addressable units.

I don't think for example a sort of Frankenstein backend monster where all the less common downstream features get lumped in together would be a good idea either. There surely is a more elegant solution.

If we do reach consensus on this idea I would be happy to take the responsibility for coordinating a working group for all interested parties to get the idea moving forward.

To put my cards on the table, I'm currently updating a word addressable DSP backend from version 3.9 to top of tree and obviously thinking of how to minimise the pain going forward.

Sean Kilmurray
CML Microcircuits (UK) Ltd
o:  +44(0) 1749 881 915
e:  skilmurray at cmlmicro.com<mailto:skilmurray at cmlmicro.com>
w: www.cmlmicro.com<http://www.cmlmicro.com/>

Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191119/e3552253/attachment.html>
-------------- next part --------------
There has been two rounds of discussion on the mailing list this year in relation to addressing the assumptions LLVM makes in relation to the size of  bytes, addressable unit sizes and use of magic numbers[1][2]. There has been consensus on moving forward but the stumbling block is testing. 

[1] https://lists.llvm.org/pipermail/llvm-dev/2019-May/132080.html
[2] http://lists.llvm.org/pipermail/llvm-dev/2019-October/136115.html

The community is wary about accepting changes that break current assumptions without in tree testing. While I agree with this wholeheartedly  we have  kind of ended up in a catch-22 situation.  It is hard to move forward on this issue without an in tree target, but  none of those needing the changes upstream (myself included) can contribute their downstream backend to the upstream codebase.

The obvious solution is to have an in-tree mock backend target to test against. 

A mock target does not have to be a working backend. It just has to appear to be a working backend to the LLVM testing infrastructure. 

At this stage I’m not clear in my head what this would actually entail or if it can be done using the current infrastructure.  Would a mock need a very basic ISA for example? Would it be ok for some tests for a mock target not to have register classes or instructions defined? Can we just register components of a mock backend within the LLVM framework just for testing purposes.  Regardless I do think that a flexible solution  to implement testable changes that does not rely on a full backend implementation would be useful to the overall project.

I think a mock target that is a better idea than contributing a backend for an old architecture that may have some nonstandard  features just for testing.  Its only solution I can see that could help address the needs and concerns of both upstream and downstream users in relation to the size of bytes, chars and minimal addressable units.

I don’t think for example a sort of Frankenstein backend monster where all the less common downstream features get lumped in together would be a good idea either. There surely is a more elegant solution.

If we do reach consensus on this idea I would be happy to take the responsibility for coordinating a working group for all interested parties to get the idea moving forward.

To put my cards on the table, I’m currently updating a word addressable DSP backend from version 3.9 to top of tree and obviously thinking of how to minimise the pain going forward.

Sean Kilmurray
CML Microcircuits (UK) Ltd
o:  +44(0) 1749 881 915
e:  skilmurray at cmlmicro.com
w: www.cmlmicro.com

PLEASE READ: Information in this email, including any attachments, is
intended solely for the addressee(s). Access to this information by anyone
else is unauthorised and in these circumstances the use, disclosure, copying
or distribution of this information is strictly prohibited. If you are not the
intended recipient, please let us know by replying to the sender and
immediately delete this email from your system.
This information has been transmitted over a public network and neither 
CML nor or any of its controlled entities accepts responsibility for the
accuracy or completeness of this message. Unless otherwise stated, opinions
expressed in this e-mail are those of the author and are not endorsed by CML.