[committed][PR rtl-optimization/116420] Fix interesting block bitmap DF dataflow

[Jeff Law]

The DF framework provides us a way to run dataflow problems on 
sub-graphs.  Naturally a bitmap of interesting blocks is passed into 
those routines.   At a confluence point, the DF framework will not mark 
a block for re-processing if it's not in that set of interesting blocks.
When ext-dce sets up that set of interesting blocks it's using the wrong 
counter.  ie, it's using n_basic_blocks rather than last_basic_block. 
If there are holes in the block indices, some number of blocks won't get 
marked as interesting.
In this case the block needing reprocessing has an index higher than 
n_basic_blocks.  It never gets reprocessed and the newly found live 
chunks don't propagate further up the CFG -- ultimately resulting in a 
pseudo appearing to have only the low 8 bits live, when in fact the low 
32 bits are actually live.
Fixed in the obvious way, by using last_basic_block instead.

Bootstrapped and regression tested on x86_64.  Pushing to the trunk.

jeff

commit c9377734b798d8d311dfd3a5618dc49407703b93
Author: Jeff Law <j...@ventanamicro.com>
Date:   Thu Aug 22 12:48:49 2024 -0600

    [PR rtl-optimization/116420] Fix interesting block bitmap DF dataflow
    
    The DF framework provides us a way to run dataflow problems on sub-graphs.
    Naturally a bitmap of interesting blocks is passed into those routines.   
At a
    confluence point, the DF framework will not mark a block for re-processing 
if
    it's not in that set of interesting blocks.
    
    When ext-dce sets up that set of interesting blocks it's using the wrong
    counter.  ie, it's using n_basic_blocks rather than last_basic_block.  If 
there
    are holes in the block indices, some number of blocks won't get marked as
    interesting.
    
    In this case the block needing reprocessing has an index higher than
    n_basic_blocks.  It never gets reprocessed and the newly found live chunks
    don't propagate further up the CFG -- ultimately resulting in a pseudo
    appearing to have only the low 8 bits live, when in fact the low 32 bits are
    actually live.
    
    Fixed in the obvious way, by using last_basic_block instead.
    
    Bootstrapped and regression tested on x86_64.  Pushing to the trunk.
    
            PR rtl-optimization/116420
    gcc/
            * ext-dce.cc (ext_dce_init): Fix loop iteration when setting up the
            interesting block for DF to analyze.
    
    gcc/testsuite
            * gcc.dg/torture/pr116420.c: New test.

diff --git a/gcc/ext-dce.cc b/gcc/ext-dce.cc
index 35c06469b82..4a2503f1831 100644
--- a/gcc/ext-dce.cc
+++ b/gcc/ext-dce.cc
@@ -988,7 +988,7 @@ ext_dce_init (void)
   all_blocks = BITMAP_ALLOC (NULL);
   changed_pseudos = BITMAP_ALLOC (NULL);
 
-  for (int i = 0; i < n_basic_blocks_for_fn (cfun); i++)
+  for (int i = 0; i < last_basic_block_for_fn (cfun); i++)
     if (i != ENTRY_BLOCK && i != EXIT_BLOCK)
       bitmap_set_bit (all_blocks, i);
 
diff --git a/gcc/testsuite/gcc.dg/torture/pr116420.c 
b/gcc/testsuite/gcc.dg/torture/pr116420.c
new file mode 100644
index 00000000000..9a784f59429
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr116420.c
@@ -0,0 +1,17 @@
+/* { dg-do run } */
+/* { dg-additional-options "-fno-forward-propagate -fno-tree-ch" } */
+int a, d, e;
+char b = -1, c, f;
+int main() {
+  int g;
+  for (; d < 1; d++) {
+    g = b;
+    for (; c; c = g)
+      ;
+  }
+  f = g;
+  for (; e < 1; e++)
+    if (g >= a)
+      __builtin_abort();
+  return 0;
+}