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.

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.

Reply via email to