Elide calling invariant for classes with no invariant defined

[dlangBugzillaToGithub]

Dmitry Olshansky (@DmitryOlshansky) reported this on 2015-08-03T17:49:57Z

Transferred from https://issues.dlang.org/show_bug.cgi?id=14865

CC List

• Steven Schveighoffer (@schveiguy)

Description

See relevant discussion:
http://forum.dlang.org/thread/xdcfidwawitalwjgqzfr@forum.dlang.org?page=1

It's a common knowledge that class invariant stays injected as a call to some internal routine even if there is no user-defined invariant for a given class.
It should be elided or at the very least inlined and carried on to all of the usual optimizations to avoid redundant null checks (it seems to check for null pointer only by default). 

Citing the relevant part of discussion:

On 8/3/15 12:59 PM, Dmitry Olshansky wrote:
> On 03-Aug-2015 19:54, Steven Schveighoffer wrote:

>> ALSO, make SURE you are compiling in release mode, so you aren't calling
>> a virtual invariant function before/after every call.
>
> This one is critical. Actually why do we have an extra call for trivial
> null-check on any object that doesn't even have invariant?

Actually, that the call to the invariant should be avoidable if the object doesn't have one. It should be easy to check the vtable pointer to see if it points at the "default" invariant (which does nothing).

-Steve

[dlangBugzillaToGithub]

k.hara.pg commented on 2015-08-04T02:45:46Z

For virtual class methods, their invariant call should be virtual. For example:

class C
{
    void foo() {}
}

class D : C
{
    invariant {}
}

void main()
{
    C c = new D;
    c.foo();    // should check D.invariant
}

[dlangBugzillaToGithub]

dmitry.olsh (@DmitryOlshansky) commented on 2015-08-04T07:55:50Z

(In reply to Kenji Hara from comment #1)
> For virtual class methods, their invariant call should be virtual. For
> example:
> 
> class C
> {
>     void foo() {}
> }
> 
> class D : C
> {
>     invariant {}
> }
> 
> void main()
> {
>     C c = new D;
>     c.foo();    // should check D.invariant
> }

Could it do a test on invariant v-table slot to see if it's a default invariant?
Then if it's the default - just test for null inline, if not - call that slot.

[dlangBugzillaToGithub]

schveiguy (@schveiguy) commented on 2015-08-04T12:06:08Z

(In reply to Dmitry Olshansky from comment #2)
> Could it do a test on invariant v-table slot to see if it's a default
> invariant?
> Then if it's the default - just test for null inline, if not - call that
> slot.

Yes, that's exactly what I meant. In fact, the language could put a null pointer in that slot by default to make it easy. Although I don't understand what you mean by the "test for null inline". If the object is null, there is no vtable to check.