Idea: Ownership & lifetime escape analysis by variables in reference to
Ola Fosheim Grøstad
ola.fosheim.grostad at gmail.com
Sun May 29 12:40:22 UTC 2022
On Sunday, 29 May 2022 at 12:11:01 UTC, rikki cattermole wrote:
> I did mention elsewhere that I previously used scope as a type
> qualifier to do this.
I guess what I am saying is something like this:
I think you would get better yield for your time investment by
pursuing how to add barriers and figuring out how one could write
@trusted code in such a landscape than anything related to
advanced escape analysis in the context of verification of *D
code* (optimization is ok, because then you will choose a best
effort strategy, verification is all-or-nothing).
To understand what is needed for solid escape analysis, let us
take the two-element queue example. You could unroll the loop.
Replace ```a[0]``` with ```a0```, ```a[1]``` with ```a1``` and
all ```a[i]``` accesses with a conditional (or switch). Then
analyse this with an algorithm/solver that can deal with
branches. Or something along these lines. A lot of machinery even
for the simplest datastructure! And then we have the slice
scenarios with aliasing, where modifying the content of one slice
could modify basically any other parameter.
It would be so much easier to just add @stack as an optimization
hint where you want something to be put on the stack, and let the
compiler generate a report of where it failed, why and how to
improve the code.
(For DIP1000 to make sense it must be a able to deal with more
complexity than most of your code, otherwise it will break down
whenever you need to modify existing code.)
More information about the Digitalmars-d
mailing list