On 13 August 2017 at 23:36, Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx> wrote: > On Mon, Aug 14, 2017 at 12:12 AM, Dibyendu Majumdar > <mobile@xxxxxxxxxxxxxxx> wrote: > >> >> Actually after RC5 merge there is a change in behaviour. >> >> Previously it would would fail to compile when simplifications were turned on. >> Now: >> >> 1) Without single store shortcut it fails to compile. The error generated is: >> >> error: no result for pseudo >> minilua.c:5593:24: error: failed to output instruction load.64* >> %r13018 <- 16[VOID] >> >> minilua.c:5593:24: error: failed to output load.64* %r13018 <- 16[VOID] > > Yes. Please forget about the single store shortcut: it's broken. > But I'm not sure: do you mean "without the shortcut" or > "without the patch that remove the shortcut"? Sorry this one is with the patch that removed the shortcut. > >> 2) With single store shortcut it appears to compile successfully but >> when the executable is run against the 'dynasm' test the test fails. >> The un-simplified version works however. > > But I understood you had tried with the SSA I sent link. > Have I misunderstood? I haven't incorporated your new SSA yet. This one is with single store short cut restored. > >> Here are the linearized outputs: >> >> I am not sure this helps you. > > Not really, I was expecting the result of the preprocessing to avoid > header dependencies and use the code as you're using it. > For example, sparse doesn't know about the __DMR_C__ macro, > we're not using the same header files, not even the same platform. I can save the pre-processed output if that helps. Will send you a link. The __DMR_C__ macro is just to help me avoid constructs that Sparse LLVM cannot handle. > But really, having small testcases with a clear description of exactly > what is wrong, help a lot. Well I think that we need a combination of tests - real world programs, as well as short, to the point, tests. The way I see it - if we get problems with a real world program, we then start digging and end up with short test that reproduces the problem. Just creating simple short tests does not tend to cover all scenarios as it is impossible to construct a comprehensive test suite (unless we can reuse someone else's test suite - which is something I am trying to do). 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
