Sean Kilmurray via llvm-dev
2019-Nov-19 08:24 UTC
[llvm-dev] RFC: A mock backend target for LLVM
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.