Documentation: Remove warning that nonstandard primitive type sizes may reveal LLVM bugs

[PatrickHaecker]

Only primitive types which are a multiple of 8 bits in size can be constructed. Therefore, the documentation should not speculate about possible bugs in other non-reachable cases.

Additionally, it's not clear whether these LLVM bugs still exist now that C allows all integers sizes.

[oscardssmith]

It would be pretty nice if we could enable support for arbitrary size primitive types. LLVM should be able to do so now that C Rust and Zig all support it.

[PatrickHaecker]

Yes, this would be nice, but unfortunately out-of-scope for this PR.

Arbitrary bit sized primitives need at least two large changes to be really useful (each worth at least one separate PR):

• switching all the size logic to not only account bytes, but allow for accounting bits – this is not only a huge change, but might make things slower and/or remove support for very large sizes
• packing fields closer than what C does, because otherwise padding typically makes all potential space savings void, e.g. a struct consisting of an Int24 and an Int8 results in a 64 bit field with the C memory layout which Julia follows.

I am currently working on two packages which would mostly circumvent these issues. However, I need to clarify whether we'll open-source them.

[LilithHafner]

"Sizes used above" refers to 2 .^ (3:7), so the clause this PR removes isn't about multiples of 8 bits but about sizes that are larger or not powers of 2.

An accurate title for this PR would be "Remove warning that nonstandard primitive type sizes may reveal LLVM bugs"

[PatrickHaecker]

Yes, this would be nice, but unfortunately out-of-scope for this PR.

Maybe I was too fast. Supporting arbitrary sized primitives which have a byte-sized sizeof might actually be possible within the scope of this PR (I have not evaluated this). It would mean that there would be no space savings at all and all we would get would be the modular arithmetic.

It would open a can of worms for discussions about how widen should work and whether all the types need to be defined by the user and what to do about signed when only the unsigned type is defined, but at least it would be a step in the direction of implementing them in Base. Would that be seen as useful?

This could make one of the two mentioned packages obsolete in the long run.

[LilithHafner]

Is this not already supported?

julia> primitive type T 24 end

julia> sizeof(T)
3

[oscardssmith]

What we're talking about here is primitive type T 23 end

[fingolfin]

As @LilithHafner already pointed out, the removed sentence did not refer to the "multiples of 8 bits" but rather to "sizes [...] used above", i.e. "8, 16, 32, 64, 128"

So the question then is: we sure that e.g. 24 or 48 work fine now and there are no LLVM bugs to be encountered? Then removing this sentence makes sense -- but I'd feel better about that if there were some actual tests in the test suite exercising that?

[PatrickHaecker]

BitIntegers.jl's test suite covers 24, 200, 256, 512 and 1024 bits with more than 500 lines of test files.

We are also using non-power-of-two byte sizes in the company I work for and do not have observed a single LLVM bug.

C, Rust and Zig should use the same LLVM code paths.

Proving the absence of bugs is hard. I have the feeling that we treat this differently compared to what we normally do: Normally we assume that LLVM works correctly and we normally do not mention bugs in other software we use. Shouldn't we have proof of bugs if we say so?

[oscardssmith]

I have the feeling that we treat this differently compared to what we normally do

I think this is just an instance of once bitten, twice shy. We know LLVM used to have a bunch of bugs here. That said, given BitIntegers tests, I think this is good to go.

[rfourquet]

The deleted comment used to be true, but I'm not aware of current LLVM (or Julia) bugs with these primitive types.