How to write int64=int32*int32 in a standard/portable and efficient way? [closed]

Answer 1

Built-in arithmetic expressions only exits for homogeneous operand types. Any expression involving mixed types implies integral promotions, and the arithmetic operation itself is only ever defined for and applied to homogeneous types.

Choose either int32_t or int64_t.

As you probably understand correctly, for both choices of type arithmetic operations (at least +, - and *) are susceptible to UB by overflow, but there can be no overflow when operating on two int64_ts which both can be represented as int32_ts. So for example the following works:

int64_t multiply(int32_t a, int32_t b)
{
    // guaranteed not to overflow, and the result value is equal
    // to the mathematical result of the operation
    return static_cast<int64_t>(a) * static_cast<int64_t>(b);
}

As an example, here is how GCC translates this to x86 and x86_64 on Linux (note the different calling conventions):

multiply(int, int):

// x86 (32-bit, "-m32 -march=i386")     x86-64 ("-m64 -march=x86-64")
// args are on the stack                args are in EDI, ESI
// return in EDX:EAX                    return in RAX

mov     eax, DWORD PTR [esp+8]          movsx   rax, edi
                                        movsx   rsi, esi
imul    DWORD PTR [esp+4]               imul    rax, rsi
ret                                     ret

Answer 2

You've already indicated how to do this in a standard, portable, and efficient way:

int64_t mul(int32_t x, int32_t y) {
    return (int64_t)x * y;
    // or static_cast<int64_t>(x) * y if you prefer not to use C-style casts
    // or static_cast<int64_t>(x) * static_cast<int64_t>(y) if you don't want
    // the integral promotion to remain implicit
}

---

Your question seems to be about a hypothetical architecture that has assembly instructions corresponding to the function signatures

int64_t intrinsic_mul(int32_t x, int32_t y);
int64_t intrinsic_mul(int64_t x, int64_t y);
int64_t intrinsic_mul(int64_t x, int32_t y); // and maybe this too

and, on this hypothetical architecture, the first of these has relevant advantages, and furthermore, your compiler fails to use this instruction when compiling the function above, and on top of all that, it fails to provide access to the above intrinsic.

I expect such a scenario to be really rare, but if you truly find yourself in such a situation, most compilers also allow you to write inline assembly, so you can write a function that invokes this special instruction directly, and still provides enough metadata so the optimizer can make somewhat efficient use of it (e.g. using symbolic input and output registers so the optimizer can use whichever registers it wants, rather than having the register choice hardcoded).