Are there 128bit architectures to even support this yet?

@jwaldrip 64bit architectures don't mean the maximum number they can process is 64bits it means that the pointer or address size is 64bits. x86 has been able to partially handle 128bit numbers since sse2 (it can put them into one register but they have limited instructions to use them), we even have avx512 now, but for most things you do with an i128, LLVM generates emulation code.

Thank you for the clarification. I did not know that 64but architectures supported it.

Support for 128bit integers is good idea. GeoIP databases use uint128 type, for example.

I'm still not sure 128 bit integers is widely supported: https://github.com/zig-lang/zig/tree/master/std/special/compiler_rt

We can always merge this and remove it later if we find something is blocking this.

@asterite I was under the impression that LLVM embedded it's own compiler_rt somehow. They seem to have re-implemented it in zig. I'm not entirely sure of the logistics of how it's linked in though.

Yes, it's a bit confusing. In any case, when the time comes, we can implement compiler-rt in Crystal if that's really needed.

@asterite I'm sure the LLVM project will do a much better and more optimised job than us. I don't see why we would.

OK, so here's a proof Int128 doesn't work out of the box. This is on Centos 32 with the new compiler:

[vagrant@localhost ~]$ crystal eval 'p Int128::MAX'
I-nt128.o: In function `*Int128@Int#remainder<Int32>:Int128':
Int128:(.text+0x135d): undefined reference to `__modti3'
I-nt128.o: In function `*Int128@Int#tdiv<Int32>:Int128':
Int128:(.text+0x1602): undefined reference to `__divti3'
collect2: ld returned 1 exit status
Error: execution of command failed with code: 1: `cc "${@}" -o '/home/vagrant/.cache/crystal/crystal-run-eval.tmp'  -rdynamic  -lpcre -lgc -lpthread /opt/crystal/src/ext/libcrystal.a -levent -lrt -ldl -L/usr/lib -L/usr/local/lib`

It seems we will need to define a bunch of methods to effectively support this.

In any case this is all experimental, we might as well remove this feature entirely if it's too complex to implement.

We don't need to define them, I think we just need to link llvm compiler-rt.

Ah, I see. Maybe a discussion for omnibus-crystal (I don't know how to do that)

We should just do what clang does, which is just to include the library in the linker command. If worst comes to worst we can just redistribute compiler-rt ourselves.

To include the library in the linker command we must ship the library with the compiler. It's a new dimension I didn't expect to happen.

We "ship" llvm-ext.so and libcrystal.a

The 0.24.0 pre-release was finally built with LLVM 3.9.1 - @asterite's comment above was done with the old 3.8 - so we should re-check if the error still happens.

@asterite on crystal master with LLVM 5 I see __divti3 in the binary:

$ nm test | grep ti3
000000000008b150 t __divti3
000000000008b2b0 t __modti3

perhaps this is an automatic thing then?