Hi Chris, On 19 August 2017 at 11:56, Christopher Li <sparse@xxxxxxxxxxx> wrote: > On 8/19/17, Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx> wrote: >> I think it is an excellent idea to create a bunch of careful tests to >> assess / validate the changes. Perhaps the tests should cover various >> scenarios including switch statements, gotos, computed gotos, looping >> constructs, etc. And specific uses of globals, pointers, locals etc. >> > > That is the idea for the test suite. To test how sparse handle > different source code. > Yes. I have a growing set of tests but I only check the final result is correct - i.e. the code can be run (both with and without simplifications) and will produce expected results. I do not check whether the Sparse IR is optimum or not, as I have been more focussed on getting the right outcome. > There is also the idea of the debug version of sparse. Instead > having the fix input source. It will do dynamic verification > of sparse at run time. e.g. If there is a slow and reliable way > to generate SSA conversion. Then in the debug version will do > both the slow and reliable way and the new fast and optimal way. > Then compare notes to draw conclusion that the new way *is* better. > AT least not worse than the old way. In this case I want to verify > that, the new method at least cover all the variable converted > by the old method. Including variable used by pointers. > Sure but this is kind of hard to do - because to validate something you need a definition of what is "good" or "expected". Ideally of course the output will be correct and at least as optimum as before - but I would rather it is correct first. Regards Dibyendu -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
