Part 1 of well-defined copy-elision (second attempt)

[andrewrk]

Not satisfied with how the code was looking in #1652, I'm tossing out that work and starting over. This branch uses the IR system directly to implement copy elision, instead of awkwardly patching over it.

The goals of this branch are the same:

• Existing code works with no changes. No new syntax or builtin functions are introduced.
• Guarantees that memcpy will not happen in many places. See result location mechanism (previously: well defined copy eliding semantics) #287
• Makes debug builds compile faster
• Makes debug builds run faster
• (unrelated) Fixes the implementation of writing 0xaa bytes to uninitialized memory in debug builds.
• Paves the way for the coroutines rewrite (See syntax for guaranteed coroutine frame allocation elision #1260 (comment)) var foo = async bar().

This does not solve the problem of how to access the result location of a function, (e.g. #287 (comment)). That is left for a future change.

Note that clang already generates code like this. This PR is actually Zig catching up with Clang in this particular area.

Checklist:

• scalar variable declaration
• scalar variable declaration to undefined
• scalar variable declaration with no explicit type
• fix alignment of variables
• var decl initializing to global const
• var decl initializing to aggregate runtime var
• aggregate variable declaration
• variable declaration with undefined
• function returning result of another function
• assignment of function call
• assignment of undefined
• implicit cast optional wrap
• implicit cast optional wrap when payload is integer
• return const struct
• if bool with aggregate types
• if bool with scalar types
• if optional with aggregate types
• if optional with scalar types
• if error with aggregate types
• if error with scalar types
• while bool with aggregate types
• while bool with scalar types
• while optional with aggregate types
• while optional with scalar types
• while error with aggregate types
• while error with scalar types
• for with aggregate types
• for with scalar types
• switch on scalar type
• switch on aggregate type
• result locations that require stack allocations
• returning a scalar value
• implicit cast payload to error union
• implicit cast error code to error union comptime
• implicit cast error code to error union runtime
• double implicit cast
• double implicit cast using fn call syntax
• implicit *[N]T to []T
• assignment of non function call
• double implicit cast when payload is integer, fn call
• implicit array to slice
• double implicit cast when payload is integer, no fn call
• runtime union init
• comptime union init
• runtime struct init
• comptime struct init
• runtime array init
• comptime array init
• fn call in parameter expressions with implicit casting to parameters
• cmpxchg
• @sliceToBytes
• slicing syntax
• orelse
• catch with identifier expression
• catch with fn call expression
• catch with other expression which requires stack alloca
• catch access of the error code
• .?
• try
• catch unreachable with identifier expression
• catch unreachable with fn call expression
• catch unreachable with other expression which requires stack alloca
• fn call parameters
• @noInlineCall / @inlineCall parameters
• labeled block
• comptime code
• fn ptr vs method call
• audit all usage of ir_lval_wrap
• write a new kind of test that looks at the LLVM IR output and add cases for all the above
• fix test regressions
• look over the diff and identify any more test cases
• add behavior test case for @sizeOf(?error)
• look over the diff and delete commented out code and no longer used Zig IR instructions.
• figure out what the llvm ir fn signature should be for error unions and optionals. sret? should the error value / null value be a pointer argument?
• re-enable stack traces in bootstrap and in the default panic handler

See each commit message in this branch for example Zig/LLVM code.

Some interesting tidbits:

• a catch b is no longer syntactic sugar for if (a) |x| x else |_| b. The former provides copy elision; the latter does not. The if expression creates a result location for a, whereas the catch expression does not create a result location.
• try a is no longer syntactic sugar for if (a) |x| x else |e| return e. Same explanation.
• a orelse b is no longer syntactic sugar for if (a) |x| x else b. However, a.? is still syntactic sugar for a orelse unreachable.

[andrewrk]

This branch also started going in a design direction and with a code quality that I was not comfortable with. I have backported all the extra stuff from this branch back into master in 581edd6 and when tackling copy elision I will try a third approach.

The third approach involves breaking IR pass 2 (the analysis pass) into sub-phases:

1. Each instruction is given the type and is_comptime of each of its parameters, and it must return its type and is_comptime of itself, and whether it needs a result location.
2. Each instruction is given the value of each of its parameters, and given a result location if requested, told whether it should emit a comptime or untime value, and it must return its value.

With this framework in place, in IR pass 1, result location instructions will be generated to track result locations throughout expressions. However unlike in this pull request, they will be lazy. Pass 1 will only create the tree structure of result locations, correlated to the corresponding instructions. In the dual phased Pass 2, result locations will be resolved with full type information, which is a key difference.

The separate is_comptime computation helps when there are "peer" expressions, for example an if expression or a switch expression. Each "prong" has the is_comptime value computed, and if all of them are comptime-known, then all of them are analyzed as comptime. Otherwise all of them are analyzed as runtime.

This will also fix this particularly tricky test case, as mentioned in #1682 (comment)

export fn entry(cond: bool, a: i8, b: i32) void {
    const x = if (cond) a else b;
}

So the plan is to close this branch, and then branch again from master. However, I think there are some important things to work on before embarking on a third copy elision attempt, such as merging the outstanding pull requests, and some other features to get into 0.4.0 besides copy elision.

Master branch is open for business.