You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The thing is that _d_newitemT allocates garbage-collected memory, which is cleaned up at program termination, incl. destructing %.gc_struct.i.i, so the store to %.vthis.i.i etc. cannot be elided.
Removing the noalias function attribute from _d_newitemT 'fixes' the testcase. I haven't found anything related in the LLVM 14 changelog.
The text was updated successfully, but these errors were encountered:
Dropping the noalias attribute is indeed the right thing to do here. _d_newitemT does not satisfy the noalias return contract, because the object is also accessible to whatever is invoking the destructor on the object storage.
Thx @nikic. _d_newitemT keeps track of its allocations, so the returned pointer escapes from the callee. From the spec:
On function return values, the noalias attribute indicates that the function acts like a system memory allocation function, returning a pointer to allocated storage disjoint from the storage for any other object accessible to the caller.
I guess there are hardly any allocators satisfying noalias return then?
Input IR: current3.txt
With LLVM 13 (
opt -O3
), the_Dmain
function is perfectly optimized to:With LLVM 14.0.0, it's a meager and invalid:
The thing is that
_d_newitemT
allocates garbage-collected memory, which is cleaned up at program termination, incl. destructing%.gc_struct.i.i
, so the store to%.vthis.i.i
etc. cannot be elided.Removing the
noalias
function attribute from_d_newitemT
'fixes' the testcase. I haven't found anything related in the LLVM 14 changelog.The text was updated successfully, but these errors were encountered: