Initial implementation of the 128-bit integers #35954
Conversation
|
r? @arielb1 (rust_highfive has picked a reviewer for you, use r? to override) |
nagisa
force-pushed
the
i-give-you-one-twenty-eight
branch
from
aa98158 to
16c01cb
Compare
|
|
||
| pub trait Encoder { | ||
| type Error; | ||
|
|
||
| // Primitive types: | ||
| fn emit_nil(&mut self) -> Result<(), Self::Error>; | ||
| fn emit_uint(&mut self, v: usize) -> Result<(), Self::Error>; | ||
| fn emit_u128(&mut self, v: u128) -> Result<(), Self::Error>; |
There was a problem hiding this comment.
This is scary, but I think since rustc-serialize on crates.io is separate and deriving wasn't changed, it should work?
There was a problem hiding this comment.
Yeah I guess. I’m more worried about a similar addition to the Hash trait.
|
☔ The latest upstream changes (presumably #35764) made this pull request unmergeable. Please resolve the merge conflicts. |
nagisa
force-pushed
the
i-give-you-one-twenty-eight
branch
from
5a8e99d to
603d409
Compare
|
☔ The latest upstream changes (presumably #35906) made this pull request unmergeable. Please resolve the merge conflicts. |
nagisa
force-pushed
the
i-give-you-one-twenty-eight
branch
from
603d409 to
dbcd45a
Compare
|
☔ The latest upstream changes (presumably #36066) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Any news on this? It would be really great to have 128 bit integer support. |
|
Was waiting on #35021 to land; didn’t notice it had already. May rebase and finish this tomorrow. |
This commit introduces 128-bit integers. Stage 2 builds and produces a working compiler which understands and supports 128-bit integers throughout. The general strategy used is to have rustc_i128 module which provides aliases for iu128, equal to iu64 in stage9 and iu128 later. Since nowhere in rustc we rely on large numbers being supported, this strategy is good enough to get past the first bootstrap stages to end up with a fully working 128-bit capable compiler. In order for this strategy to work, number of locations had to be changed to use associated max_value/min_value instead of MAX/MIN constants as well as the min_value (or was it max_value?) had to be changed to use xor instead of shift so both 64-bit and 128-bit based consteval works (former not necessarily producing the right results in stage1).
Dangling a carrot in front of a donkey.
Stage 1 can’t really handle negative 128-bit literals, but an equivalent bit-not is fine
Also fix the leb128 tests
Fixes rebase fallout, makes code correct in presence of 128-bit constants.
Causes ICEs otherwise while trying to dump AST
|
Does this affect |
|
Status update: I have some intrinsics ported, but I can’t get the multiplication to work for some reason, I’ll need more time to investigate that.
Eventually we’ll want to make this happen. In optimised code LLVM should be pretty smart about not using the whole 128 bits when it doesn’t need to. Moreover storage of i128 is not that much slower than storage of i64, so it should be of little concern. |
nagisa
force-pushed
the
i-give-you-one-twenty-eight
branch
from
eeca54d to
b2df420
Compare
|
ping @nagisa, any update on this? |
With a better algorithm (based on Horner's Method, as recommended by Ted Krovetz), a bigint isn't necessary, just 64-64 multiplication. This addresses the XXX_QUESTION around NH and Hash. Further efficiency is gained by avoiding a physical modulo operation, instead using the identity (a % (2^61 - 1)) = (a >> 61) + (a & (2^61 -1)), and borrow's from Ted's reference implementation. This pulls in the extprim crate as an interim measure until rust-lang/rust#35954 is released, which provides native 128-bit words.
|
@est31 is working on finishing this in the issue referenced above. |
i128 and u128 support Adds support for 128-bit integers. Rebased version of #35954 , with additional improvements. Thanks @nagisa for mentoring this PR! Some of the problems that were resolved: * [x] Confirm that intrinsics work on 32 bit platforms and fix them if needed * Wait for #37906 to get fixed, so that work on intrinsics can be completed *(worked around by merging the PR on my local setup)* * [x] Investigate and fix linkcheck failure [plugin-breaking-change] cc #35118
i128 and u128 support Brings i128 and u128 support to nightly rust, behind a feature flag. The goal of this PR is to do the bulk of the work for 128 bit integer support. Smaller but just as tricky features needed for stabilisation like 128 bit enum discriminants are left for future PRs. Rebased version of #37900, which in turn was a rebase + improvement of #35954 . Sadly I couldn't reopen #37900 due to github. There goes my premium position in the homu queue... [plugin-breaking-change] cc #35118 (tracking issue)
This commit introduces 128-bit integers. Stage 2 builds and produces a working compiler which understands and correctly handles 128-bit integers.
The general strategy used is to have rustc_i128 module which provides aliases for iu128, equal to iu64 in stage0 and iu128 later. Since nowhere in rustc we rely on large numbers being supported, this strategy is good enough to get past the first bootstrap stages to end up with a fully working 128-bit capable compiler.
This PR contains no compiler-rt implementations yet (will get around implementing anything necessary before landing) and I feel that I didn’t quite catch all the locations where iu64 need to be converted to iu128 in the compiler yet. No effort were made to update the Makefiles (will get around it tomorrow, I hope) or old trans (since it is getting removed soon anyway) either.
During implementation the only really problematic issue which has been discovered is that there seems to be no way to generate debug info for 128-bit discriminants (
DIBuilder::createEnumeratortakes 64bit value), so I didn’t put much effort into supporting the i128 discriminants at all.All being said, the stage2 test suite seems to pass on a x86_64 linux machine. I don’t have any means to test any other targets (either virtualised or not) by myself at least till early autumn.
cc #35118
[plugin-breaking-change] due to changes to the AST.