On Wed, Dec 16, 2020 at 2:25 PM Luc Van Oostenryck
<luc.vanoostenryck@xxxxxxxxx> wrote:
>
> I suppose that it is fine for you that I your SoB instead of the
> 'Originally-by' I used here?
Either works for me.
Some of the cases I saw (from my very quick look) were because of
annoying zero extensions that should have been optimized away.
Example:
static inline unsigned char bytemask(int bit)
{
return ~(1<<bit);
}
unsigned char maskout(unsigned char a, int bit)
{
return a & bytemask(bit);
}
note how this is all safe, because everything is operating on just bytes.
But sparse complains:
t.c:3:21: warning: zero-extending a negation - upper bits not negated
because obviously the usual C type expansion to 'int'.
But that really is because sparse is benign stupid, and leaves those
type expansions around even though they then get truncated down again.
You can see it in the code generation too:
Zero-extend, and then truncate:
zext.32 %r2 <- (8) %arg1
shl.32 %r5 <- $1, %arg2
trunc.8 %r6 <- (32) %r5
then do the 'not' in 8 bits, because we did that part ok:
not.8 %r7 <- %r6
and then the zero-extend and truncate thing again:
zext.32 %r9 <- (8) %r7
and.32 %r10 <- %r2, %r9
trunc.8 %r11 <- (32) %r10
and then the return in 8 bits:
ret.8 %r11
because sparse doesn't do the simplification to just do the shl and
and in 8 bits (but sparse *does* do the simplification to do the 'not'
in 8 bits).
So the warning comes from the fact that we kept that zero extend
around, even though it really wasn't relevant..
I don't know how many of the false positives were due to things like
this, but at least a couple were.
Linus
