Support arbitrary bitwidth integers

[mkitti]

LLVM currently has support for arbitrary bitwidth integers.
https://llvm.org/docs/LangRef.html#integer-type
https://reviews.llvm.org/rG5f0903e9bec97e67bf34d887bcbe9d05790de934
https://reviews.llvm.org/rG6c75ab5f66b4
https://discourse.llvm.org/t/rfc-add-support-for-division-of-large-bitint-builtins-selectiondag-globalisel-clang/60329?u=programmerjake

Rust:
https://internals.rust-lang.org/t/pre-rfc-arbitrary-bit-width-integers/15603
rust-lang/rfcs#2581

Zig:
https://ziglang.org/documentation/master/#Primitive-Types

C23:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2709.pdf

[imciner2]

While I would like arbitrary integers for something I eventually want to do, my understanding is exposing them is a fairly dangerous gamble because the LLVM backends may not properly handle integers that are not multiples of 8-bits (or at least that is my recollection of part of the discussion that was had leading to #35526, but that discussion was unfortunately lost to the Slack-hole). As such, they open up more places for bugs and segfaults to creap in.

[oscardssmith]

we definitely shouldn't do this before we see how it plays out in other languages. for sizes larger than 64 bits, I think this might not have benefits over an efficient bigint, and for smaller sizes, freaking with non byte aligned objects will be a total pain to implement.

[imciner2]

I don't know if we would actually be responsible for aligning the data in this case. From what was mentioned in #39315, it sounds like the LLVM backend should do that for us as it sees fit (e.g. it should ingest the non-standard integers and convert them to a form usable value in the backend). The main issue is that LLVM backends might not have support for doing that, or might not do it properly.

I know that the usecase I have in mind, I wouldn't want any alignment done before passing to the backend. Since my eventual goal is to try taking the LLVM IR and feeding it into the OneAPI or Vitis HLS toolchains and get hardware out of it. So for the hardware I don't want padding, because that padding would negate the benefit of using a smaller integer type in the first place.

[mkitti]

We are about to see how it plays out in C I believe. Let's see if n2709, proposing _BitInt(N) makes it into the next C standard, C23. That I think will be our cue to proceed on this.

[quinnj]

Following this conversation for https://github.com/JuliaStrings/InlineStrings.jl.

[workingjubilee]

An update of N2709 was accepted: N2763.
The last round of _BitInt(N) fixes that I am aware of are in N3035.
You can read N3088 which is the latest C23 draft and includes the latest spec for _BitInt(N), as I understand it.

[ThePhD]

As the Project Editor for C who integrated these changes (and has a thousand more things they need to do to stuff them into the C standard), please go ahead.

Please add this.

Please go even further beyond than the rest of us have ever dreamed of going.

[mkitti]

Thanks for the encouragement @workingjubilee and @ThePhD . It's time to hack this up and see where we get stuck.

I hope it is as easy as removing some artificial limitations for primitive type in Julia itself and in BitIntegers.jl.

cc: @rfourquet

julia> using BitIntegers          
julia> BitIntegers.@define_integers 24
@uint24_str (macro with 1 method)

julia>  x = uint24"1"             0x000001

julia> @code_llvm identity(x)
;  @ operators.jl:513 within `identity`
define i24 @julia_identity_371(i24 zeroext %0) #0 {
top:
  ret i24 %0
}

julia> BitIntegers.@define_integers 12
ERROR: invalid number of bits in primitive type Int12
Stacktrace:
 [1] top-level scope
   @ ~/.julia/packages/BitIntegers/6M5fx/src/BitIntegers.jl:60

[mkitti]

The immediate obstacle is Core._primitivetype will throw an error for non-multiples of 8.

julia/src/builtins.c

Lines 1540 to 1541 in f64463d

	if (nb < 1 || nb >= (1 << 23) || (nb & 7) != 0)
	jl_errorf("invalid number of bits in primitive type %s",

We can work around this by calling jl_new_primitivetype directly, but this will basically just round up to the nearest byte-multiple.

julia> raw_new_primitive_type(name, nbits, mod = Main, supertype = Unsigned, parameters = Core.svec()) =
           @ccall jl_new_primitivetype(
               pointer_from_objref(name)::Ptr{Nothing},
               pointer_from_objref(mod)::Ptr{Nothing},
               pointer_from_objref(supertype)::Ptr{Nothing},
               pointer_from_objref(parameters)::Ptr{Nothing},
               nbits::Csize_t
           )::Ref{DataType}
raw_new_primitive_type (generic function with 5 methods)


julia> const foobar = raw_new_primitive_type(:foobar, 17)
foobar

julia> typeof(foobar)
DataType

julia> sizeof(foobar)
3

julia> x = Core.checked_trunc_uint(foobar, 5);

julia> @code_llvm identity(x)
;  @ operators.jl:526 within `identity`
; Function Attrs: uwtable
define i24 @julia_identity_567(i24 zeroext %0) #0 {
top:
  ret i24 %0
}

The fundamental issue is that jl_datatype_layout_t tracks the size in bytes.

julia/src/julia.h

Lines 512 to 531 in f64463d

	typedef struct {
	uint32_t size;
	uint32_t nfields;
	uint32_t npointers; // number of pointers embedded inside
	int32_t first_ptr; // index of the first pointer (or -1)
	uint16_t alignment; // strictest alignment over all fields
	uint16_t haspadding : 1; // has internal undefined bytes
	uint16_t fielddesc_type : 2; // 0 -> 8, 1 -> 16, 2 -> 32, 3 -> foreign type
	uint16_t padding : 13;
	// union {
	// jl_fielddesc8_t field8[nfields];
	// jl_fielddesc16_t field16[nfields];
	// jl_fielddesc32_t field32[nfields];
	// };
	// union { // offsets relative to data start in words
	// uint8_t ptr8[npointers];
	// uint16_t ptr16[npointers];
	// uint32_t ptr32[npointers];
	// };
	} jl_datatype_layout_t;

While we may still need the size in bytes, we may want to track how many bits are unused (0 - 7). Thus we need to steal 3 bits from somewhere, perhaps from the padding field?

[oscardssmith]

We also could just (at least for an initial version) only allow multiple of 8 sizes. I'm not sure how many people need a 57 bit integer. (4 and 12 bit would be somewhat nice for DNA/HDR images and stuff, but rounding to the byte isn't exactly unreasonable).

[mkitti]

We also could just (at least for an initial version) only allow multiple of 8 sizes

We already do this.

julia> primitive type foobar <: Unsigned 24 end

julia> primitive type foobar40 <: Unsigned 40 end

With BitIntegers.jl we get a fully functional integer:

julia> BitIntegers.@define_integers 24
@uint24_str (macro with 1 method)

julia> uint24"4096"
0x001000

julia> int24"4096"
4096

julia> int24"4096" + uint24"4096"
0x002000

This issue is about getting those 4 and 12 bit integers.

julia> primitive type UInt4 <: Unsigned 4 end
ERROR: invalid number of bits in primitive type UInt4
Stacktrace:
 [1] top-level scope
   @ REPL[129]:1

julia> primitive type UInt12 <: Unsigned 12 end
ERROR: invalid number of bits in primitive type UInt12
Stacktrace:
 [1] top-level scope
   @ REPL[130]:1

[workingjubilee]

It's also worth considering older color formats as well, which may e.g. pack 5 bits per R, G, and B.

Obviously, those pack into 16 bits nicely, possibly using extra bit for a mask, and so it's not that hard to manually unpack, do the math, mask, repack, etc. etc. But allowing people to not have to write such code, reimplementing it over and over, is what these types are for.

[mkitti]

Are those 15 bits packed together such that 8 pixels would only take up 15 bytes (120 bits)?

My main foray into this is camera hardware that uses 12-bit or 14-bit analog-to-digitial conversion and then transferring those packed bits into a raw binary file.

One could use SIMD based shuffles to unpack the camera frame data into uint16, but there were some applications where we just wanted to sample a few values.

There are two distinct issues I see here:

1. Creating integer types with a certain precision, offset, padding, byte order, and signed/unsigned. Here I'm mostly concerned about precision. The actual size of the integer may be in integral bytes. We could have a 12-bit or a 15-bit precision integer that takes up two bytes.
2. Packing bit integers into bytes and unpacking them. Two 12-bit integers only need to take up three bytes for example.

My current sense is that the compiler, LLVM specifically, knows how to do item 1 above, specifically regarding precision.

Item 2 is interesting, helped by item 1, but needs more specification. I would be surprised if the compiler knows how to do this.

I want to take advantage of existing compiler features, particularly if they are in use by clang for C23 BitInt support.

[vtjnash]

Feel free to make a PR to change that to bits instead of bytes internally. Be aware the compiler is free to add padding, and will therefore likely round up to bytes for performance.

[oscardssmith]

As I understand, the purpose of non byte aligned types is for dealing with very large arrays, so the scalar representation doesn't matter as much as what happens when you have 1 million of them in an array.