On 10/05/16 19:20, Bernd Schmidt wrote: > On 05/10/2016 08:05 PM, Richard Biener wrote: >> On May 10, 2016 7:02:33 PM GMT+02:00, Jeff Law <l...@redhat.com> >> wrote: >>> Well, not if we take Bernd's idea and create a new backend for >>> testing purposes. If we want to know/test what reload's doing, we >>> cons up the appropriate RTL for that testing backend, set the right >>> flags and call reload() then look at the result.
>> >> Hmm, I guess that some test cases rely on specific patterns being >> (not) present so we'd have one backend per testcase ... (Or .md file >> snippets per testcase). > > You could have any pattern you want in such a machine description, and if you > run into conflicts or if you want to test different variants, you can have -m > switches. > 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 ! regards Ramana > > Bernd >
