> On Tue, 19 Nov 2024, Jan Hubicka wrote: > > > > > > > The problem with the two states we had/have is that they are too extreme. > > > > > > Our old one (i.e. those "mC" etc.) is too strong and doesn't have any > > > backup in the standard, I think the PR101480 testcase is perfectly > > > valid C++ and so it probably isn't a good idea to enable such behavior > > > by default; with an extra switch sure, user promises not to rely on it > > > and the optimization can be done. > > > > > > The current one (i.e. those "m " etc.) are too weak, otherwise we wouldn't > > > be discussing this PR, it really penalizes too much code in the wild. > > > > I have WIP patch (which needs polishing for next stage 1) to extend > > modref to detect functions doing allocations that does not escape to > > global state as pure/const since allocation+deallocation should not be > > observable. > > I think that's the wrong way around - what the C++ standard seems to > imply is that we should be able to elide the allocation if the > allocated memory is unused and we are allowed to ignore side-effects > on global memory. But iff the allocation takes place the side-effects > on global memory are of course visible.
If we allow function that does allocation+deallocation to be pure and later out call to it since we know that eveyrhing it computes is dead or redundant, it is the same as inlining it, optimizing out everything it calculates (since it is dead or redundant) and then removing the allocatin pair as dead. So it should be safe with wording of the standard + the extra assumption that new/delete is const/pure in fnspec way (no side effects on memory) as done by Jakub's patch. If we expect new/delete to clobber global memory but still be optimizable out (our current default) the transformation would be still possible, but needs extra logic to handle "if executed it may change something but doing so is optional". Honza > > That is, in DCE terms, global memory use/def should not make > the allocation/deallocation necessary. In practice this will > then still need two DCE runs to optimize things fully, the first > can elide the allocation but only the second can elide things > made necessary by the allocation functions. > > IIRC that's what is implemented right now, correct? > > For the allocation to not be barriers for other optimization there's > no guarantee from the C++ standard and so we can add another flag. > But allocation functions only reading but not storing global memory > and users caring sounds like not going to be common to be worth > optimizing for. > > Richard.
