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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
I'm not sure if this is supposed to be fixed yet.  For the comment#2 testcase
I now get

  <bb 2> [local count: 1073741824]:
  _1 = __atomic_load_1 (&_ZGVZ4mainE3foo, 2);
  if (_1 == 0)
    goto <bb 4>; [33.00%]
  else
    goto <bb 3>; [67.00%]

  <bb 3> [local count: 956811341]:
  goto <bb 6>; [100.00%]

  <bb 4> [local count: 354334800]:
  _2 = __cxa_guard_acquire (&_ZGVZ4mainE3foo);
  if (_2 != 0)
    goto <bb 5>; [33.00%]
  else
    goto <bb 3>; [67.00%]

  <bb 5> [local count: 116930483]:
  MEM[(struct string_view *)&foo] ={v} {CLOBBER};
  MEM[(struct string_view *)&foo].str = "bar";
  MEM[(struct string_view *)&foo].len = 3;
  __cxa_guard_release (&_ZGVZ4mainE3foo);

  <bb 6> [local count: 1073741824]:
  _9 = foo.len;
  _8 = (int) _9;
  return _8;

so we fail to CSE foo.len because __cxa_guard_release possibly clobbers it
(it's global memory).

Note the clobbering is necessary to prevent code motion across the
lock primitives.

Note that __cxa_guard_release also prevents removing the .str initialization
since only the .len member is ever inspected.  As noted static initialization
would improve this quite a bit.

Reply via email to