On Sun, Aug 6, 2017 at 9:51 PM, Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx> wrote: > Hi Chris, > > I agree that simplifications must not result in incorrect code (in my > case correct code is more valuable than efficient code) - and in this > particular example, the C code is legal and correct and this is not an > instance of an uninitialized variable because in the C code the > variable is assigned a value prior to it being accessed. Just for the sake of completeness, it's not exactly simplification that produce incorrect code. Like often, it's the interaction of several things, here related to uninitialized vars (s3 is not initialized, it shouldn't matter but it currently does). > I am not sure that this is easy to fix though - as the original IR > does not capture the intent of the C program. It shouldn't be too hard. > Maybe you could have a > separate IR instruction to assign value to a bit field - rather than > using load/and/or sequence. This will enable the original IR to > reflect the intent of the C program more accurately and hopefully > enable the simplification phase can handle it correctly. Yes. I already thought about it several times but I never was able to convince myself that it would be worth. For dealing correctly with the case here we need *more*, *smarter* simplifications. With specific instructions, it would be a bit easier (but probably only a little bit) and will want these kind of simplifications anyway so the new instructions will only add more code, need to deal with similar situation in two different places, ... This is related to the fact that sparse IR is quite low-level, as we already talked about. Maybe it would be good to first linearize to less low-level IR and then lower the IR. I think something like this will be needed soon or later. -- Luc -- 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
