Int128 compiler-rt methods (Int128 literal support part 1)

[BlobCodes]

Includes the compiler-rt methods from #11196.

The modulo and dision methods do not work on windows due to the lack of SIMD support in crystal.

[BlobCodes]

In rust's compiler-builtins, the method __muloti4 needed to be in extern "unadjusted" unstead of extern "C". Is it possible to do this in crystal?

AFAIK should be @[CallConvention("unadjusted")], but this is not a valid call convention in crystal.

The __muloti4 specs fail on windows, but this shouldn't need SIMD.

[asterite]

It seems that's a calling convention in Rust, but I don't see it listed in LLVM: https://llvm.org/docs/LangRef.html#calling-conventions

I don't know what they call "unadjusted".

You can put a CallConvetion annotation to functions and methods:

https://crystal-lang.org/reference/syntax_and_semantics/annotations/built_in_annotations.html#callconvention

The values there should be updated.

Unfortunately I can't figure out what's this "unadjusted" in Rust... 🤔

[asterite]

I found something: rust-lang/rust#38482 (comment)

Good luck!

(I still think we should drop support for Int128 and UInt128)

[BlobCodes]

The muloti4 specs pass on my local vm (llvm 11.1)
Maybe this got fixed in a version between what the CI is using and 11.1 ?

I don't think it would be worth fixing this if this is the case

[straight-shoota]

Specs fail on win32 with both LLVM 10.0 and 11.1 for me. So it appears to be something different. But don't worry about that.
We've already established that Windows support is a sizable task. That should be worked on on its own, after this PR has landed.

[BlobCodes]

Specs fail on win32 with both LLVM 10.0 and 11.1 for me. So it appears to be something different. But don't worry about that.
We've already established that Windows support is a sizable task. That should be worked on on its own, after this PR has landed.

Just checked again, looks like I forgot to replace the win32_std_spec.cr 😄
Yeah, it does fail on 11.1.

[BlobCodes]

I think this should be ready to review now

[asterite]

Add now-possible int operations to specs

I think this one should be reverted. We shouldn't use new compiler features in std specs. Otherwise you can't run std specs without compiling a new compiler.

[asterite]

(though maybe that changed, no idea... if CI passes it's fine, maybe someone changed that rule...)

[BlobCodes]

(though maybe that changed, no idea... if CI passes it's fine, maybe someone changed that rule...)

Everything necessary to pass the specs is in the prelude, the compiler source hasn't changed.
Should be fine AFAIK

[beta-ziliani]

Thanks!