Bring back div_rem

[alexcrichton]

Tracking issue for #850

[alexcrichton]

cc @quantheory

[Boscop]

Any update on this? :)

[vi]

Shall it avoid giving negative remainders unlike %?

[Lokathor]

When you divide -1234 by 10, your remainder is -4.

I think the advantage of div_rem is that the computer is already doing both at once, it's just throwing away part of the work instead of instead of letting us keep both parts.

[dignifiedquire]

What exactly would it need to push this forward?

[Centril]

@dignifiedquire I'd just write a PR against https://github.com/rust-lang/rust/ and then T-libs can decide what to do.

[Lokathor]

Make sure to spec it as const from the start (for integers at least)

Edit: oh crap no const-if yet, nevermind i guess

[AaronKutch]

I want to add a set of uX::wrapping_div_rem(lhs, rhs) -> (uX, uX) functions as a way to guarantee that __udivmodti4 and the like are called, and not have to rely on the compiler backend to combine operations. However, someone encountered an LLVM error where the target sparc-unknown-linux-gnu cannot lower any function that returns a tuple of two u128s. If the function were added, wouldn't that completely break 32-bit SPARC targets unless the LLVM issue is resolved?

[programmerjake]

I'd imagine rustc could add a workaround to do the return lowering in rustc if the LLVM bug is not easy to fix or we want to support old LLVM versions.

[AaronKutch]

Is there someone who wants to tackle the problem? I might try myself, although I have no idea where to begin. I've never messed with code lowering before.

[programmerjake]

It seems to work fine from clang: https://gcc.godbolt.org/z/8xbrWE