Calling convention and not-variable overhaul: extractvalue/extractelement/insertvalue/insertelement

[shawnl]

Proposal: pass everything as value (including user's pointers of course), and then fix it up as needed.

See #1481 tracking bug.

Current almost everything goes through the stack, including function calls, and then we rely on out calling convention code and llvm to eliminate the stack allocations. We should be doing this the other way around: we should only use stack allocations if they are necessary, and if the C ABI calls for a stack allocation we should only then convert to a stack allocation. (LLVM really should implement the C ABI for us, and it appears the PowerPC backend does this, but we have to live with it the way it is on ARM and x86 until it is fixed).

The reason it should be the other way around is that we should be using extractvalue/extractelement/insertvalue/insertelement whenever possible. (if the index into an array is not constant this is not possible, and it has to be copied to the stack). We have to do this overhaul anyways in order to be array-type accesses of vectors my_vector[3], and note that while you can take an address of a vector &my_vector, you cannot take the address of a vector element (&my_vector[3] is a compile error).

Doing this is made tricky because we do not have types resolved until the final second pass of analyze, and it is tricky do instruction switch-a-roo in a single pass.

This is blocking #2698 (see my code here shawnl@a622694 which cannot just return bool), it is blocking a PowerPC port (WIP shawnl@40dd53e which includes a first attempt at this bug that didn't work), and it is blocking element access of vector as mentioned above.

[shawnl]

Here is the example, where you can see that variables are always put onto the stack for no real reason:

pub export fn aaa55(x: bool) bool {
 return !x;
}

pub export fn aaa66(x: bool) bool {
 return aaa55(x);
}

becomes

; Function Attrs: nobuiltin nounwind
define i1 @aaa55(i1) #0 !dbg !770 {
Entry:
  %1 = alloca i1, align 1
  %x = alloca i1, align 1
  store i1 %0, i1* %x, align 1
  call void @llvm.dbg.declare(metadata i1* %x, metadata !775, metadata !DIExpression()), !dbg !776
  %2 = load i1, i1* %x, align 1, !dbg !777
  %3 = icmp eq i1 %2, false, !dbg !779
  store i1 %3, i1* %1, !dbg !780
  ret i1 %3, !dbg !780
}

; Function Attrs: nobuiltin nounwind
define i1 @aaa66(i1) #0 !dbg !781 {
Entry:
  %1 = alloca i1, align 1
  %x = alloca i1, align 1
  store i1 %0, i1* %x, align 1
  call void @llvm.dbg.declare(metadata i1* %x, metadata !783, metadata !DIExpression()), !dbg !784
  %2 = load i1, i1* %x, align 1, !dbg !785
  %3 = call i1 @aaa55(i1 %2), !dbg !787
  store i1 %3, i1* %1, !dbg !788
  ret i1 %3, !dbg !788
}

[andrewrk]

Here is the example, where you can see that variables are always put onto the stack for no real reason:

they're put on the stack for 2 reasons:

• so that there is debug info for local variables
• so that you can take the address of parameters

if you look at clang IR it does the same thing.