> > 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
^ optimize
> 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
