[Bug tree-optimization/112307] Segmentation fault with -O1 -fcode-hoisting

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112307

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jamborm at gcc dot gnu.org

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
There is no actual code-hoisting happening, the only effect of -fcode-hoisting
is that we perform a round of value-numbering which does perform quite a bit
of simplification in the program.  In particular it simplifies
CompositeMesh::Intersections down to just

  <bb 2> [local count: 1073741826]:
  D.72649 ={v} {CLOBBER};
  MEM[(struct optional *)&D.72649 + 8B] ={v} {CLOBBER};
  MEM[(union _Storage *)&D.72649 + 8B] ={v} {CLOBBER};
  MEM[(struct __as_base  &)&<retval>] ={v} {CLOBBER};
  MEM <unsigned char> [(struct Enumerator *)&<retval>] = 1;
  MEM <unsigned char> [(struct Enumerator *)&<retval> + 16B] = 0;
  MEM <struct Intersection *> [(struct Enumerator *)&<retval> + 8B] =
&MEM[(struct __box *)&<retval>]._M_value;
  MEM <unsigned char> [(struct Enumerator *)&<retval> + 16B] = 1;
  <retval>.end_reached_ = 0;
  D.72649 ={v} {CLOBBER(eol)};
  return <retval>;

by optimizing a leading condition:

+  <bb 2> [local count: 1073741826]:
   D.72649 ={v} {CLOBBER};
   MEM[(struct optional *)&D.72649 + 8B] ={v} {CLOBBER};
   MEM[(union _Storage *)&D.72649 + 8B] ={v} {CLOBBER};
   MEM[(struct __as_base  &)&<retval>] ={v} {CLOBBER};
   MEM <unsigned char> [(struct Enumerator *)&<retval>] = 1;
   MEM <unsigned char> [(struct Enumerator *)&<retval> + 16B] = 0;
-  _12 = MEM[(const struct _Optional_base *)&<retval> +
8B]._M_payload.D.71902._M_engaged;
-  if (_12 != 0)
-    goto <bb 4>; [66.00%]
-  else
-    goto <bb 3>; [34.00%]
-
-  <bb 3> [local count: 365072225]:
   MEM <struct Intersection *> [(struct Enumerator *)&<retval> + 8B] =
&MEM[(struct __box *)&<retval>]._M_value;
   MEM <unsigned char> [(struct Enumerator *)&<retval> + 16B] = 1;
-  goto <bb 12>; [100.00%]

the load ligns up exactly with the immediately preceeding store.

A preceeding value-numbering pass still sees

<bb 2> [local count: 1073741824]:
D.72600 ={v} {CLOBBER};
MEM[(struct single_view *)&D.72600] = 1;
MEM[(struct optional *)&D.72600 + 8B] ={v} {CLOBBER};
MEM[(union _Storage *)&D.72600 + 8B] ={v} {CLOBBER};
MEM[(struct _Optional_payload_base *)&D.72600 + 8B]._M_engaged = 0;
MEM[(struct __as_base  &)&<retval>] ={v} {CLOBBER};
<retval>.enumerator_ = D.72600;
_12 = MEM[(const struct _Optional_base *)&<retval> +
8B]._M_payload.D.71853._M_engaged;
if (_12 != 0)

but SRA then wrecks this I think:

Created a replacement for D.72600 offset: 0, size: 8: SR.74D.80925
Created a replacement for D.72600 offset: 128, size: 8: SR.75D.80926
Removing load: <retval>.enumerator_ = D.72600;
...
  <bb 2> [local count: 1073741824]:
  D.72600 ={v} {CLOBBER};
  SR.74_13 = 1;
  MEM[(struct optional *)&D.72600 + 8B] ={v} {CLOBBER};
  MEM[(union _Storage *)&D.72600 + 8B] ={v} {CLOBBER};
  SR.75_68 = 0;
  MEM[(struct __as_base  &)&<retval>] ={v} {CLOBBER};
  MEM <unsigned char> [(struct Enumerator *)&<retval>] = SR.74_13;
  MEM <unsigned char> [(struct Enumerator *)&<retval> + 16B] = SR.75_68;
  _12 = MEM[(const struct _Optional_base *)&<retval> +
8B]._M_payload.D.71853._M_engaged;
  if (_12 != 0)

that's

#1  0x0000000001c186f1 in sra_modify_assign (
    stmt=<gimple_assign 0x7ffff383b1e0>, gsi=0x7fffffffd9d0)
    at /home/rguenther/src/trunk/gcc/tree-sra.cc:4490
4490                  generate_subtree_copies (racc->first_child, lhs,
(gdb) l
4485                  if (dump_file)
4486                    {
4487                      fprintf (dump_file, "Removing load: ");
4488                      print_gimple_stmt (dump_file, stmt, 0);
4489                    }
4490                  generate_subtree_copies (racc->first_child, lhs,
4491                                           racc->offset, 0, 0, gsi,
4492                                           false, false, loc);

note we pass "write" as false here, and 'lacc' is null.  But if we cannot
analyze the LHS I wonder why we haven't disqualified the RHS here?

I'll note that while this does look like a serious issue -fno-tree-sra
fixes that but that doesn't seem to fix the testcase :/

The difference in main() remains though:

@@ -195,9 +305,7 @@
   if (_16 != 0)
     goto <bb 13>; [11.00%]
   else
-    goto <bb 14>; [89.00%]
-
-  <bb 14> [local count: 105119324]:
+    goto <bb 3>; [89.00%]

   <bb 3> [local count: 955247973]:
   _25 = MEM[(const struct _Optional_base *)&intersections +
8B]._M_payload.D.71902._M_engaged;
@@ -261,15 +369,7 @@
   <bb 12> [local count: 955630224]:
   _34 = _26 + 1;
   MEM[(struct Intersection * &)&intersections + 8] = _34;
-  _36 = &MEM <struct EnumeratorRange> [(void *)&intersections + 1B] != _34;
-  _22 = &MEM <struct EnumeratorRange> [(void *)&intersections + 1B] == _34;
-  intersections.end_reached_ = _22;
-  if (&MEM <struct EnumeratorRange> [(void *)&intersections + 1B] == _34)
-    goto <bb 13>; [11.00%]
-  else
-    goto <bb 15>; [89.00%]
-
-  <bb 15> [local count: 850510900]:
+  intersections.end_reached_ = 0;
   goto <bb 3>; [100.00%]

   <bb 13> [local count: 118111600]: