https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109448
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |missed-optimization
Priority|P3 |P2
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed| |2023-04-12
CC| |hubicka at gcc dot gnu.org
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
<bb 2> [local count: 1073741824]:
promise = {};
D.22193 ={v} {CLOBBER};
MEM[(struct __as_base &)&D.22193] ={v} {CLOBBER};
MEM[(union _Variadic_union *)&D.22193] ={v} {CLOBBER};
MEM[(struct _Uninitialized *)&D.22193] ={v} {CLOBBER};
MEM[(struct _Variant_storage *)&D.22193]._M_index = 0;
_16 = __atomic_load_4 (&MEM[(const struct __atomic_base *)&promise]._M_i, 5);
if (_16 != 0)
goto <bb 3>; [0.00%]
else
goto <bb 4>; [100.00%]
<bb 4> [local count: 1073741824]:
_20 = MEM[(const struct variant
*)&D.22193].D.21735.D.21220.D.21138.D.21006.D.20892.D.20796._M_index;
_21 = (signed char) _20;
_22 = (long unsigned int) _21;
if (_22 == 1)
goto <bb 12>; [33.33%]
without checking it looks like we fail to CSE _M_index to 0 here and
run into the unreachable code region dominated by BB 12. That's
because __atomic_load_4 is a full barrier since D.22193 excapes
in the call to _M_reset later in the function (yep, our escape handling
isn't flow-sensitive).
We sofar made no attempts in relaxing the barrier-ness of __atomic_* for
any of the memory order parameters, not sure if in this case the CSE
would be valid when D.22193 were global memory.
Btw, we fail to mod-ref analyze the _M_reset this as not escaping because
it escapes through the _M_release call done and that function is
out-of-line:
_10 = &MEM[(struct __aligned_membuf *)this_4(D)]._M_storage;
std::__exception_ptr::exception_ptr::_M_release (_10);
there's currently no way to annotate the std::__exception_ptr methods
manually, we'd need to add this capability somehow.
