Invalid `InsertValueInst` when awaiting multiple coroutines in one expression

[salvatore-abello]

Description

Codon aborts while compiling an async program that awaits two coroutines in the same print expression.

Reproduction

import asyncio

async def a():
    print("b")

async def b():
    print("c")

async def main():
    p1 = a()
    p2 = b()

    print(await p1, await p2)

asyncio.run(main())

Run:

codon run test.py

Actual behavior

Invalid InsertValueInst operands!
  %31 = insertvalue { {}, {} } undef, ptr %.reload28, 0, !dbg !24057
Invalid InsertValueInst operands!
  %29 = insertvalue { {}, {} } undef, ptr %.reload28, 0, !dbg !24070
Invalid InsertValueInst operands!
  %29 = insertvalue { {}, {} } undef, ptr %.reload28, 0, !dbg !24083
Assert failed: Generated LLVM IR is invalid and has been dumped to '_dump.ll'. Please submit a bug report at https://github.com/exaloop/codon including the code and generated LLVM IR.
Expression: !broken
Source:     /github/workspace/codon/cir/llvm/optimize.cpp:1070

The process aborts with an IOT instruction (core dumped) error.

Expected behavior

The program should run successfully and print:

b
c
None None

Environment

• Codon: 0.19.6
• OS: Fedora Linux 43 (Workstation Edition)
• Kernel: Linux 7.0.9-105.fc43.x86_64
• Architecture: x86_64
• CPU: Intel Core Ultra 7 155H

dump.ll.tar.gz

[BI71317]

@salvatore-abello
Thanks for information. It seems interesting, as it differs whether execution is given with -release option or not.

$ codon run -release mre.py 
b
c
None None

$ codon run mre.py 
Invalid InsertValueInst operands!
  %31 = insertvalue { {}, {} } undef, ptr %.reload28, 0, !dbg !22731
Invalid InsertValueInst operands!
  %29 = insertvalue { {}, {} } undef, ptr %.reload28, 0, !dbg !22744
Invalid InsertValueInst operands!
  %29 = insertvalue { {}, {} } undef, ptr %.reload28, 0, !dbg !22757
Assert failed:  Generated LLVM IR is invalid and has been dumped to '_dump.ll'. Please submit a bug report at https://github.com/exaloop/codon including the code and generated LLVM IR.

[BI71317]

@arshajii

Summary

Codon can generate invalid LLVM IR when an await result has zero allocation size, e.g. NoneType, and the value remains live across another suspend point.

MRE 1: Zero Size Return for Coroutine

This is exactly same script given from above comment:

import asyncio

async def a():
    print("b")

async def b():
    print("c")

async def main():
    p1 = a()
    p2 = b()
    print(await p1, await p2)

asyncio.run(main())

Result

If build is given without -release option,

codon build mre.py

Invalid InsertValueInst operands!
  %31 = insertvalue { {}, {} } undef, ptr %.reload28, 0

This is invalid because first argument in tuple arguments for print expects {}, but the inserted value is ptr.

MRE 2: Non-Zero sized return for Coroutine

This results somewhat different return, if coroutine is defined with non-zero type return:

import asyncio

async def a():
    return 1

async def b():
    return 2

async def main():
    p1 = a()
    p2 = b()
    print(await p1, await p2)

asyncio.run(main())

result

$ ./mre2_non_release 
1 2

Root Cause

LLVM coroutine frame layout intentionally does not allocate a real frame field for zero-sized values.

in llvm-project\llvm\lib\Transforms\Coroutines\CoroFrame.cpp:

// For an alloca with size=0, we don't need to add a field and they
// can just point to any index in the frame. Use index 0.
if (FieldSize == 0) {
  return 0;
}

The same coroutine frame also stores coroutine runtime header fields first:

// Add header fields for the resume and destroy functions.
(void)B.addField(FnPtrTy, std::nullopt, /*header*/ true);
(void)B.addField(FnPtrTy, std::nullopt, /*header*/ true);

So field 0 is not a user payload slot. It is the resume function pointer.

LLVM’s own coroutine test coro-zero-alloca.ll expects zero-sized allocas to alias frame index 0, but does not treat that address as containing a meaningful zero-sized value payload:

%foo.Frame = type { ptr, ptr, i32, i16, i1 }
...
  %a0 = alloca [0 x i8], align 1
  %a1 = alloca i32, align 4
  %a2 = alloca [0 x i8], align 1
  %a3 = alloca [0 x i8], align 1
  %a4 = alloca i16, align 2
  %a5 = alloca [0 x i8], align 1
  %coro.alloc = call ptr @malloc(i64 24)
  %resume.addr = getelementptr inbounds nuw %foo.Frame, ptr %coro.alloc, i32 0, i32 0
  store ptr @foo.resume, ptr %resume.addr, align 8
  %destroy.addr = getelementptr inbounds nuw %foo.Frame, ptr %coro.alloc, i32 0, i32 1
  store ptr @foo.destroy, ptr %destroy.addr, align 8
  %a0.reload.addr = getelementptr inbounds %foo.Frame, ptr %coro.alloc, i32 0, i32 0
  %a1.reload.addr = getelementptr inbounds %foo.Frame, ptr %coro.alloc, i32 0, i32 2
  %a2.reload.addr = getelementptr inbounds %foo.Frame, ptr %coro.alloc, i32 0, i32 0
  %a3.reload.addr = getelementptr inbounds %foo.Frame, ptr %coro.alloc, i32 0, i32 0
  %a4.reload.addr = getelementptr inbounds %foo.Frame, ptr %coro.alloc, i32 0, i32 3
  %a5.reload.addr = getelementptr inbounds %foo.Frame, ptr %coro.alloc, i32 0, i32 0
  %index.addr1 = getelementptr inbounds nuw %foo.Frame, ptr %coro.alloc, i32 0, i32 4

The C comparison also points in the same direction: empty aggregate return/argument/copy paths are lowered as void or zero-byte copies, not as meaningful payload loads/stores.

Therefore, the invalid Codon behavior is not that LLVM maps zero-sized frame fields to index 0. That is expected LLVM behavior.

The problem is that Codon still materializes zero-sized values as if they were normal storable/reloadable payloads:

• _promise(p1) returns {}.
• That {} result remains live across another suspend.
• Coroutine lowering maps the zero-sized spill slot to frame field 0.
• Codon/LLVM IR then reloads field 0 as ptr, because the actual field is the resume function pointer.
• Tuple construction consumes that ptr as if it were the original {} value.
• insertvalue { {}, {} } ... ptr becomes invalid IR.

Codon should preserve the semantic value NoneType, yeah for sure, but avoid physically storing/loading zero-sized values through normal LLVM storage/liveness paths.