On Sun, 1 Oct 2006, Al Viro wrote: > > This stuff comes from handling smaller-than-int bitwise types (e.g. __le16). > The problem is in handling things like > __be16 x, y; > ... > if (x == (x & ~y)) > The code is bitwise-clean, but current sparse can't deduce that. Al, I understand why you did it the way you did, but I think it's wrong. Why do I think it's wrong? Let me count the ways. Umm. Ok, I counted, and there's only one way. The only reason I think you're doing it wrong is that you're using this totally new separate mechanism for it (which is not a bad mechanism, but it's very much a special case), and you should not need to! The fact is, regardless of any bitwise issues, the (cast) narrower-type <op> (wider-type "&" (cast) narrower-type) should _always_ be simplified to a small-type. See? Even from a purely optimization angle, we're actually better off just noticing that the whole comparison can be done in the narrower type. Imagine this piece of code: int mask; char c, *p; if (*p == (mask & c)) where there is no bitwise stuff, a good compiler should notice on its own that it should just be done in 8 bits rather than having to convert "c" and "*p" to integers. And once you do that _generic_ optimization, your whole "fouled" thing is useless. Btw, we _already_ do this optimization for a few cases, we just didn't do it for enough cases. We do it purely for assignment statements, ie notice how git already does not warn for __le16 a, b; a = ~b; exactly because we have done a simplification of a = (implicit cast back to __le16)~(implicit cast to int)b; to just keeping everything in the narrower type.. See commit 4b6c2e63d3423931ac687f113882cec427df9f91 for details. And I _think_ we should be able to do exactly the same for this one, by simply noticing that doing a (widening-cast) a == b & (widening-cast) c is by definition throwing away the higher bits on both sides, and we can just turn it into the simpler a == c & (narrowing-cast) b instead. Of course, we can only do this with ops that don't have overflow from the narrower type (but comparisons and bitops are ok). No? Linus - 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
