Rewrite align_down with bitwise operations

[jserv]

mi_align_down_ptr was implemented with multiplication and division,
which can be converted to equivalent and deterministic bit operations.

[daanx]

Thank you for the PR @jserv ! However, I will not merge it, apologies :-( Modern C compilers will always optimize divides and multiplies, and it being static is enough for the compiler to inline if appropiate. Moreover, by using division/multiply it will work also for non-powers of 2 and give better error/warning messages in case of overflow etc.

For example,

uintptr_t testing(uintptr_t sz) {
  return _mi_align_down(sz, 4096);
}

becomes

testing(unsigned long):
        mov     rax, rdi
        and     rax, -4096
        ret

https://godbolt.org/z/zf4frzqqc

[daanx]

Ah, I see I do do this bit trick in _mi_align_up -- it makes sense of course if the alignment is unknown in which case the compiler cannot optimize more. Still, that only matters for operations where performance is paramount (in this case in the posix_memalign for example). In the os.c module this is not so important -- any OS call will completely dominate run time; so I am still not convinced; let's keep it simple where we can.

[jserv]

Compiler optimizations might only make sense when alignment is a constant. Think of the following:

static uintptr_t _mi_align_down(uintptr_t sz, size_t alignment) { return (sz / alignment) * alignment; }
static int page_size;
static int get_page_size() { return page_size; }
uintptr_t testing(uintptr_t sz) {
  page_size = 4096;
  return _mi_align_down(sz, get_page_size());
}

The generated assembly of function _mi_align_down would be: (x86_64, gcc-10.3)

_mi_align_down:
        push    rbp
        mov     rbp, rsp
        mov     QWORD PTR [rbp-8], rdi
        mov     QWORD PTR [rbp-16], rsi
        mov     rax, QWORD PTR [rbp-8]
        mov     edx, 0
        div     QWORD PTR [rbp-16]
        imul    rax, QWORD PTR [rbp-16]
        pop     rbp
        ret

Both div and imul instructions exist.

[jserv]

That was the reason why I sent another pull request #392 to enable expected compiler optimizations.