type alignment declaration

[vtjnash]

I am soliciting syntax ideas for alignment contraints on types (if Jeff approves). Below is one proposal:

type X
  a::Int32,16 #bits, underaligned (might cause segfaults due to unaligned memory access)
  b::Int32,128 #bits, overaligned
end

Additionally, we may want to be able to specify absolute offsets:

type X
  a::Int32,64 #bits, sets minimum alignment of entire type
  b::Int32,-128 #offset of 128 bits
  c1::Uint16,-128 #also offset 128 bits (creates a type union)
  c2::Uint16,-144 #remaining bits of type union
end

[pao]

cc @pao (I'll just borrow whatever you come up with in StrPack.jl.)

[StefanKarpinski]

I believe the syntax @[0-9]+ is available. I would favor indicating where the filed lies relative to the initial offset of the structure, rather than what you're doing, which seems more confusing. You could indicate padding by having a field of type None. Whether offsets should be in bits or bytes is unclear to me. I lean towards bytes, but our sizes are in bits. Example:

type X
  a  :: Int32  @0   # field .a is 32 bits and starts at offset 0
  b  :: Int32  @128 # field .b is 32 bits and starts at offset 128
  c1 :: Uint16 @128 # field .c1 is 16 bits and starts at offset 128
  c2 :: Uint16 @144 # field .c2 is 16 bits and starts at offset 144
  _  :: None   @192 # total struct size is at least 192 bits
end

[ViralBShah]

Would @ not interfere with the macro pass - or can the parser do this? As an alternative, Range syntax feels like it could be intuitive here, but it would end up with too many colons on one line.

[vtjnash]

The @ sign syntax looks good to me, if it doesn't interfere with macro parsing. Also ::. I was proposing that the negative of an absolute alignment specifies a relative alignment requirement. (Although I think the reverse of my original proposal is better). I was leaning towards using bits, to maintain consistency with the declaration of bitstypes (it's harder to remember what the alignment of :: Int32 @-8 means than :: Int32 @-64)

type X
  a  :: Int32  :: -64  # field .a is 32 bits and starts at first non-overlapping byte index, required alignment of 64 bits
  b  :: Int32  :: 128 # field .b is 32 bits and starts at offset 128
  c1 :: Uint16 :: 128 # field .c1 is 16 bits and starts at offset 128
  c2 :: Uint16 :: 144 # field .c2 is 16 bits and starts at offset 144
  _  :: None   :: 192 # total struct size is at least 192 bits
end

[StefanKarpinski]

:: already means something and this is not what it means. @128 doesn't mean anything because 128 is not a valid macro expander name. I don't think that specifying both relative and absolute alignments is important. It seems better to have only one way of doing it, and absolute placement seems much easier to understand to me: each field has a location within the structure and a size, which is already implied by its type.

[lsorber]

+1 for Stefan's @ syntax, it's quite clear even without explanation.

[eschnett]

I imagine one would want to define integer constants for the alignment, and then refer to these constants when specifying the alignment. This would e.g. allow defining several types with identical alignment, or using if statements when specifying the alignment, or using simple integer expressions for the alignment.

This would not work well with the @ syntax. An explicit keyword, e.g. aligned(64), possibly in square brackets, would allow this.

[ScottPJones]

I was just checking to see if Julia already had something like this, not just to control alignment in a structure, but of the structure itself... this is very important if you need to lay things out so that they are on cache-line boundaries (usually 32 for ARM, 64 for Intel/AMD..., 128 for POWER).
Is this PR just dead?

[elextr]

@ScottPJones I don't think Julia can control the alignment of objects, but wouldn't that be needed as well as internal organisation to ensure cache alignment?

[ScottPJones]

Julia allocates all of the memory for objects, so it can align allocations. As far as global objects (which I am also interested in aligning, C can do this with the __declspec(align(n)) or __attribute(align(n)) compiler directives... that information must be passed on to LLVM somehow.

[elextr]

Yes, what I meant is that Julia code doesn't have any way of specifying a required object alignment to its allocators, as you said "that information must be passed on to LLVM somehow".

[vtjnash]

It's perhaps worth pointing out that the gcc alignment attribute tells the compiler to assume the address is aligned, but does not guarantee alignment. For example the gcc docs suggest it may only provide int alignment. Also: http://stackoverflow.com/questions/1468513/attribute-aligned-not-working-with-static-variables

[elextr]

@vtjnash that SO points the finger at the system linker as the actual problem, but being JITed, does Julia actually use the system linker?

[vtjnash]

closing in favor of #15244