Difference between revisions of "DIP60"

From D Wiki
Jump to: navigation, search
(Added a note regarding the behaviour of @nogc in presence of optimizations. Please remove it if the note is wrong.)
Line 65: Line 65:
 
== Behaviour in presence of optimizations ==
 
== Behaviour in presence of optimizations ==
  
Using Escape Analysis the LDC2 compiler is able to remove the heap allocation from this main function when full optimizations are used. So it should be possible to annotate this main function with @nogc and compile it successfully when the Escape Analysis removes the heap allocation:
+
Using Escape Analysis the LDC2 compiler is able to remove the heap allocation from this main function when full optimizations are used. However, validity of code should not be affected by optimization settings. (Nor can it be, without intertwining the compiler frontend with each backend in rather complicated ways.) Hence the following main function cannot be annotated with @nogc even when Escape Analysis removes the heap allocation:
  
 
     __gshared int x = 5;
 
     __gshared int x = 5;

Revision as of 11:49, 18 April 2014

Title: DIP Add @nogc Function Attribute
DIP: 60
Version: 1.2
Status: Draft
Created: 2014-4-15
Last Modified: 2014-4-18
Author: Walter Bright
Links: DIP60/Archivepull request
- forum discussion

Abstract

The @nogc function attribute will mark a function as not making any allocations using the GC.

Rationale

Many users want to be able to guarantee that code will not allocate using the GC.

Description

@nogc goes in the same way that the nothrow attribute does, and is quite similar in behavior. It affects inheritance in that it is covariant. The name mangling for it will be "Ni". @nogc will be inferred for template functions in the same manner as nothrow is. @nogc will be transitive, in that all functions called by an @nogc function must also be @nogc. GC allocations in a @nogc function will be disallowed, and that means calls to operator new, closures that allocate on the GC, array concatenation, array appends, and some array literals.

No functions in the GC implementation will be marked @nogc.

Usage

@nogc int func(int a) { ... }

Static allocations should be ignored

This code (and its mutable __gshared variants) should work since the beginning:

 void foo() @nogc nothrow {
     static const err = new Error("error");
     throw err;
 }

The situation is similar to this code, that is allowed (text is not nothrow, but here it's called at compile-time):

   void foo() nothrow {
       import std.conv;
       enum msg = text(10);
   }

Behaviour in presence of optimizations

Using Escape Analysis the LDC2 compiler is able to remove the heap allocation from this main function when full optimizations are used. However, validity of code should not be affected by optimization settings. (Nor can it be, without intertwining the compiler frontend with each backend in rather complicated ways.) Hence the following main function cannot be annotated with @nogc even when Escape Analysis removes the heap allocation:

   __gshared int x = 5;
   int main() {
       int[] a = [x, x + 10, x * x];
       return a[0] + a[1] + a[2];
   }

Copyright

This document has been placed in the Public Domain.