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@cmlmicro.com

w: www.cmlmicro.com

CML disclaimer.txt (3.34 KB)