Optimization of proposed lambda expression for upcoming DIP

[Michael V. Franklin via D.gnu]

I'm currently testing the optimization for the proposed lowering 
in this upcoming DIP: https://github.com/dlang/DIPs/pull/97

Tested at https://explore.dgnu.org/ (love this tool, by the way) 
64-bit (PC) gdc 7 with -O3 -frelease

/********** Lowering expression to lambda *************/
import core.bitop;

struct S
{
    uint field;

    uint prop() @property
    {
        return field;
    }

    uint prop(uint value) @property
    {
        return field = value;
    }
}

void main()
{
    S s;
    ((auto ref _e1) => _e1.prop(_e1.prop() + 1))(s);

    // prevent compiler from optimizing the whole thing away
    volatileStore(cast(uint*)32, s.field);
}

// OUTPUT
main:
        movq    _Dmain@GOTPCREL(%rip), %rdx
        jmp     _d_run_main@PLT
        movl    (%rdi), %eax
        ret
        movl    %esi, %eax
        movl    %esi, (%rdi)
        ret
_Dmain:
        movl    $1, 32
        xorl    %eax, %eax
        ret
uint example.main().__lambda1!(example.S).__lambda1(ref 
example.S):
        movl    (%rdi), %eax
        addl    $1, %eax
        movl    %eax, (%rdi)
        ret

/****** Functionally equivalent code without lowering ***********/
import core.bitop;

struct S
{
    uint field;
}

void main()
{
    S s;
    s.field += 1;

    // prevent compiler from optimizing the whole thing away
    volatileStore(cast(uint*)32, s.field);
}

// OUTPUT
main:
        movq    _Dmain@GOTPCREL(%rip), %rdx
        jmp     _d_run_main@PLT
_Dmain:
        movl    $1, 32
        xorl    %eax, %eax
        ret

-- Analysis --
`_Dmain` is equivalent, as I expected, but what's going on with 
`main`?  Anything to be concerned about?

Mike