On Mon, 2 Mar 2020, Alexander Monakov wrote: > On Mon, 2 Mar 2020, Richard Biener wrote: > > > PR90348 is certainly entertaining. But I guess for a GSoC project > > we need a more elaborate implementation plan. The above suggesting > > of a "lifetime start" is IMHO a no-go btw. Instead I think the > > only feasible way is to make all references indirect and thus > > make both "allocation" and "deallocation" points explicit. Then > > there's a data dependence on the "allocation" statement which > > provides upward safety and the "deallocation" statement would > > need to act as a barrier in some to be determined way. That is, > > how to make optimizers preserve the lifetime end is still unsolved. > > I think a verifier that ensures that all references are dominated by > "lifetime start" and post-dominated by clobbers/lifetime-end would > be a substantial step towards that. > > Agreed that data dependence on allocation would automatically ensure > part of that verification, but then the problem with deallocation > remains, as you say.
Yes. > > IMHO whatever we do should combine with the CLOBBERs we have now, > > not be yet another mechanism. > > This seems contradictory with the ideas in your previous paragraph. > I agree though, CLOBBER-as-lifetime-end makes sense and does not > call for a replacement. CLOBBERs would just make content dead. CLOBBERs and lifetime start would be somewhat redundant if we continue to emit CLOBBERs everywhere as we do now (the C++ FE emits them at lifetime start). Richard.
