On 05/11/2016 01:06 PM, Ramana Radhakrishnan wrote:
Is there any reason why this framework cannot be used to replace a large number of scan-assembler tests in various target testsuites which are essentially testing for either a peephole, a transformation or the register allocator eliminating particular moves ? One of the problems in gcc.target/arm is the myriad of options to make skip these scan assembler tests depending on multilib options passed in from the top and I'm wondering if this gives a way out. Obviously I don't want to keep 2 copies of the md patterns just to test a peephole or what reload is doing in a test backend !
The idea of having a test backend is that it is stable, and will not diverge from the tests, while a real backend may undergo development that may periodically invalidate test rtl.
In practice I expect we might end up using both approaches, depending on the test. Ideally we'd have some unit tests to verify pass behaviour, and these could be tested with the special test backend, while any deeply target-specific tests (maybe relying on special reorg passes) could live in the normal gcc.target/.
Bernd
