struct IR layout diverges from LLVM ABI layout
Status
Scenario
For the struct {i32, f64}, the IR type table computes the size as the sum of
the field sizes and uses offsets 0 and 4. The LLVM backend, however,
represents the value as an ordinary unpacked LLVM structure {i32, double},
where double is located at offset 8 and the total size is 16.
When storing, accessing a field, or indexing an array of such structs, part of
the lowering uses packed IR offsets while LLVM load/store follows native
alignment. As a result, f64 is read starting at the wrong address and loses
its representation.
Expected behavior
Qumir should have a single, explicitly defined struct layout for IR, the VM,
and LLVM: field offsets, alignment, and final size must agree at every stage.
Another acceptable option is for the LLVM backend to use packed LLVM structs
if a packed layout is the IR's contract.
Workaround
generate explicit u8 padding fields
struct IR layout diverges from LLVM ABI layout
Status
{i32, f64}and an array of struct values.Scenario
For the struct
{i32, f64}, the IR type table computes the size as the sum ofthe field sizes and uses offsets
0and4. The LLVM backend, however,represents the value as an ordinary unpacked LLVM structure
{i32, double},where
doubleis located at offset8and the total size is16.When storing, accessing a field, or indexing an array of such structs, part of
the lowering uses packed IR offsets while LLVM load/store follows native
alignment. As a result,
f64is read starting at the wrong address and losesits representation.
Expected behavior
Qumir should have a single, explicitly defined struct layout for IR, the VM,
and LLVM: field offsets, alignment, and final size must agree at every stage.
Another acceptable option is for the LLVM backend to use packed LLVM structs
if a packed layout is the IR's contract.
Workaround
generate explicit
u8padding fields