| Message ID | b882714e-8858-491d-4e22-ae477ae6ced4@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 05/06/2016 11:18 PM, Jeff Law wrote: > > OK for the trunk? Counts as obvious, doesn't it? Bernd
On 05/09/2016 03:29 AM, Bernd Schmidt wrote: > On 05/06/2016 11:18 PM, Jeff Law wrote: >> >> OK for the trunk? > > Counts as obvious, doesn't it? It might, particularly in cases where the code is essentially unchanged in 20 years and thus we don't have nearly as much concern that the preconditions are likely to change. jeff
diff --git a/gcc/bitmap.c b/gcc/bitmap.c index 0c05512..010cf75 100644 --- a/gcc/bitmap.c +++ b/gcc/bitmap.c @@ -556,7 +556,7 @@ bitmap_find_bit (bitmap head, unsigned int bit) want, the one we want doesn't exist. */ head->current = element; head->indx = element->indx; - if (element != 0 && element->indx != indx) + if (element->indx != indx) element = 0; return element;
I was looking at a performance regression with some threading changes I'm working on and spotted this trivial cleanup. in bitmap_find_bit: /* `element' is the nearest to the one we want. If it's not the one we want, the one we want doesn't exist. */ head->current = element; head->indx = element->indx; if (element != 0 && element->indx != indx) element = 0; ELEMENT will always be non-NULL at the conditional as it was dereferenced in the prior statement. And if we look up further (not shown here), we can deduce that ELEMENT will always be non-NULL at the dereference point as well. Things have been like this since the introduction of bitmap.c in 1997. VRP will catch this, but its kind of silly to not clean this nit up at the source level. Bootstrapped and regression tested on x86_64 linux. OK for the trunk? * bitmap.c (bitmap_find_bit): Remove useless test.