Multiplication takes more than a handful of instructions if the hardware doesn't do it.

https://godbolt.org/z/ccYPaz1Pj

For this example (AVR), this is the int multiply function __mulhi3:

    00: 00 24  eor  r0, r0
    02: 55 27  eor  r21, r21
    04: 00 c0  rjmp .+0
    06: 08 0e  add  r0, r24
    08: 59 1f  adc  r21, r25
    0a: 88 0f  add  r24, r24
    0c: 99 1f  adc  r25, r25
    0e: 00 97  sbiw r24, 0x00
    10: 01 f0  breq .+0
    12: 76 95  lsr  r23
    14: 67 95  ror  r22
    16: 00 f0  brcs .+0
    18: 71 05  cpc  r23, r1
    1a: 01 f4  brne .+0
    1c: 80 2d  mov  r24, r0
    1e: 95 2f  mov  r25, r21
    20: 08 95  ret

I mean, pedantically speaking the normal zig operators do control flow in their operators, in checked mode they panic on overflow, etc (you're not supposed to recover from them but I suppose it's possible). There's probably (internal) control flow in the saturating operators, etc.

Not always. I’ve seen division and atomic operations stay as function calls to libgcc. However, semantics of these are well-defined either way, unlike user-defined operators, so existence of a hidden call is at most an inconvenience when linking code from different compilers.