[RFA] Remove useless test in bitmap_find_bit.

[RFA] Remove useless test in bitmap_find_bit.

[Jeff Law]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

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?


[-- Attachment #2: P --]
[-- Type: text/plain, Size: 451 bytes --]

	* bitmap.c (bitmap_find_bit): Remove useless test.

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;

Re: [RFA] Remove useless test in bitmap_find_bit.

[Bernd Schmidt]

On 05/06/2016 11:18 PM, Jeff Law wrote:
>
> OK for the trunk?

Counts as obvious, doesn't it?


Bernd

Re: [RFA] Remove useless test in bitmap_find_bit.

[Jeff Law]

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