dip1000 and preview in combine to cause extra safety errors
Nick Treleaven
nick at geany.org
Mon Jun 13 16:22:54 UTC 2022
On Monday, 13 June 2022 at 11:14:36 UTC, deadalnix wrote:
> If the value stays on stack - which is all that DIP1000 can
> check for anyways, then modern backend can track it. LLVM for
> instance, will annotate function parameter to indicate if they
> escape or not and do so recursively through the callgraph.
LLVM might not have the library source code.
> LDC is already able to do stack promotion when escape analysis
> proves something doesn't escape.
>
> This is WAY preferable because:
> - It works regardless of annotations from the dev.
So does scope inference (when it's done).
> - It is always correct, it will not fubar existing @system
> code.
I'm not sure why someone would have written scope in @system code
unless they didn't understand it's only checked in @safe code.
The stack promotion optimization is the only reason to use it in
@system code AIUI.
> - Inlining is likely to uncover more opportunity to do this,
> there is no point doing it before.
Then the LLVM optimization and the scope optimisation are both
needed for the best code in all cases.
> Doing this type of optimization to explicitly free elements on
> heap is worth it. But DIP1000 doesn't allow to track this
> reliably.
Please can you provide an example? (There's one Timon came up
with in your scope thread recently, Walter's working on that).
More information about the Digitalmars-d
mailing list