result location mechanism (part of no-copy semantics)

[andrewrk]

• Previous effort (1) Part 1 of well-defined copy elision #1652
• Previous effort (2) Part 1 of well-defined copy-elision (second attempt) #1682

This is the third attempt, which is working beautifully working.

After this is done, the door is opened to some important core language improvements, most notably the coroutine rewrite (#2377) and well-defined copy eliding semantics (#287). The main idea here is that you can look at any expression and easily understand where the result will be written to. For example:

var x = foo();

With the new result location semantics, the function call foo() is guaranteed to directly initialize the memory that the variable x is associated with. Note that this is a semantic guarantee, regardless of optimization level. What's neat about this is that it works with complex expressions, for example:

var x = Data{
    .field1 = 26,
    .field2 = if (condition) bar() else baz(),
};

Here, the function calls to bar() and baz() are guaranteed to directly initialize x.field2. Have a look at the earlier commit messages for more demonstrations of zig code and the corresponding LLVM IR it's generating.

Merge checklist:

• Get compiler_rt tests passing
• Get the behavioral tests passing
• Fix labeled break from a block to use proper result location semantics
• Get libuserland.a building successfully
• Fix stack trace / debug info regression
• Get standard library tests passing. Do a git diff with master to make sure all tests are uncommented.
• Fix the vector alignment issue that @mikdusan found
• Fix the union initialization issue that @mikdusan found
• Fix compile errors with self hosted compiler (@mikdusan's reduction)
• Get the self-hosted compiler building I'm allowing this to regress until The Coroutine Rewrite Issue #2377 is done.
• Merge master & resolve conflicts
• Get compile error tests passing
• All tests passing on Linux
• All tests passing on macOS
• All tests passing on Windows
• Work with @shawnl to get Add many llvm float intrinsics. #2709 merged into master so that I can be the one to resolve the conflicts
• Offer to run the test suite for some zig community members' projects to find more regressions

Some more items, which I may postpone by filing issues rather than doing them in this branch:

• better behavior for implicit casts. for example these introduce an extra allocation/memcpy:

    var x: [1]i32 = [_]i32{1};
    var x = ([1]i32)([_]i32{1});

whereas this one does not:

    var x = [_]i32{1};

but all 3 should be semantically identical.

• This example has less than ideal LLVM IR:

export fn entry() void {
    _ = mul(true, 1) catch undefined;
}
pub fn mul(c: bool, answer: i32) error{Overflow}!i32 {
    return if (c) error.Overflow else answer;
}

It creates an unnecessary stack variable.

Preliminary Performance Comparison

result location branch, debug zig build, 622 behavioral tests

                Name       Start         End    Duration     Percent
          Initialize      0.0000      0.0035      0.0035      0.0009
   Semantic Analysis      0.0035      1.1861      1.1826      0.3220
     Code Generation      1.1861      1.3654      0.1793      0.0488
    LLVM Emit Output      1.3654      3.6289      2.2635      0.6163
  Build Dependencies      3.6289      3.6302      0.0013      0.0003
           LLVM Link      3.6302      3.6728      0.0426      0.0116
               Total      0.0000      3.6728      3.6728      1.0000

master branch, debug zig build, 616 behavioral tests

                Name       Start         End    Duration     Percent
          Initialize      0.0000      0.0026      0.0026      0.0008
   Semantic Analysis      0.0026      0.8965      0.8939      0.2586
     Code Generation      0.8965      1.0744      0.1779      0.0514
    LLVM Emit Output      1.0744      3.4139      2.3395      0.6767
  Build Dependencies      3.4139      3.4158      0.0019      0.0006
           LLVM Link      3.4158      3.4571      0.0413      0.0120
               Total      0.0000      3.4571      3.4571      1.0000

It's not a fair comparison because more tests have been added in the result location branch. However, note that the percent of time spent in LLVM Emit Output is a smaller percent, and the time spent in Semantic Analysis is a higher percent. This is a good thing, because it means that Zig's IR code - which I hastily coded up without regard for performance in this branch - can be more easily improved than LLVM's perf. The LLVM IR that this branch produces is significantly simpler for LLVM to compile, and significantly fewer calls to memcpy at runtime.

[andrewrk]

Brilliant, thanks @mikdusan for the patch, looks good. Do you want to make a pull request so you can get credit for it (you can select copy-elision-3 instead of master as your destination branch)?

[shawnl]

../src/analyze.cpp:4716:63: error: ‘void* memcpy(void*, const void*, size_t)’ writing to an object of type ‘struct ConstExprValue’ with no trivial copy-assignment [-Werror=class-memaccess]
memcpy(const_val, entry->value, sizeof(ConstExprValue));

with gcc-9