audit alignment

[andrewrk]

For example, we set size_in_bits on a bool to 1. But then later when making an array type we use this value and multiply by the array size. Is that right?

On structs when making the member debug type we set the alignment of members and calculate the offset in bits to each member. Are we doing it right?

We also set the alignment for structs and have the option to set alignment on local variables and parameters, and more.

Related, figure out exactly what is the difference between packed structs and normal structs. Will LLVM re-order fields to improve alignment? Or is that our job? If LLVM does it, how do we know which values to give to the debug info? If we do it then we need to add that to codegen.

• audit alignment of struct themselves, as well as fields within the struct
• audit alignment of parameters to functions
• audit alignment of local variable allocations, and of loads and stores. look at the llvm api what instructions take alignment parameters, and use clang to generate C code to make sure we're doing it correctly.
• search the lang ref for "align" and make sure we're setting the alignment of all the instructions that take alignment as an argument

[andrewrk]

The answer to everything is include/llvm-c/Target.h

[andrewrk]

• I propose an align keyword. Here's how it works:

// global variable
var foo: u8 align 4 = 100;

comptime {
    assert(@typeOf(&foo) == &align 4 u8);
    const slice = (&foo)[0..1];
    assert(@typeOf(slice) == []align 4 u8);
}

// function
fn derp() align 8 -> void {
    // local variable
    const array: [8]u8 align 8 = undefined;
    assert(@typeOf(&array[0]) == &align 8 u8);
}

// packed struct
const baz: packed struct {
    a: u32,
    b: u32,
} = undefined;
comptime {
    assert(@typeOf(&baz.b) == &align 1 const u32);
}

// bit field
const blah: packed struct {
    a: u3,
    b: u3,
    c: u2,
} = undefined;
comptime {
    assert(@typeOf(&blah.b) == &align 1:3:6 const u3);
    // not allowed to slice pointers with bit offsets: (&blah.b)[0..1] is a compile error
}

• When the pointer has ABI alignment of the child type, the alignment can be unspecified: &align @cAbiAlignOf(T) T == &T. Same for slices.

• A pointer with a larger alignment can be implicitly casted to a pointer with a smaller alignment.

• Same for slices (add tests).

• @ptrCast gives a compile error if you try to cast a pointer from a smaller alignment to a pointer with a larger alignment.

• Slice widening / slice narrowing gives a compile error if you try to increase alignment.

• @alignCast(align_byte_count, PtrType) gives a pointer with a possibly increased pointer alignment, and has a runtime safety check.

• @alignCast works for slices too.

• @memset and @memcpy builtins use the alignment property of the pointer arguments to set alignment.

• Alignment of every field of a packed struct is 1.

• A struct on the stack with unspecified alignment can have the preferred alignment for the first field.

• A struct on the stack with specified alignment uses the specified alignment for the first field.

• Related code: A slice can have volatile just like a pointer.

• Do similar thing with alignment in pointers and slices with fn pointers.

• @ptrCast should preserve the alignment

• slice widening should preserve the alignment

• generic functions can use comptime parameters to set alignment (verify the IR)

• with an aligned array, getting pointer of an element known at runtime is ABI alignment. getting pointer of an element with a compile-time known value is alignment known. (iterate backwards over the alignment, dividing by 2 every iteration on the alignment until you reach ABI alignment. if the compile time known array index is mod that value, it's that alignment. worst case ABI alignment.)

• cmpxchg protection

• global variables

• functions

• load

• store

• alloca

• memcpy

• memmove

• memset

• parameters

• alignstack on function attribute

• align(4) instead of align 4 and make it expression instead of primary expression