> The -m32 option sets int, long, and pointer types to 32 bits, and generates code that runs on any i386 system.
That restricts you to the smaller register set, removes all amd64 instructions, and uses the x86 ABI (on Linux, parameters are passed on the stack instead of in registers.) I suspect that this is why your program became slower, as opposed to using 32-bit pointers.
It sounds like x32 is poorly supported by Linux and x86 would be better supported.
1. Kernel support to be enabled in order to make x32 system calls. Checking /proc/config.gz on Arch Linux, my kernel does not appear to have it enabled.
2. An x32 toolchain to build against. For gcc and glibc, that would mean re-compiling as described here: https://sourceware.org/glibc/wiki/x32
3. All of the libraries you link with to be recompiled for the x32 ABI.
x86 is definitely easier to build against since there's still legacy software using it, whereas almost nobody seems to use x32. However, over the long term I expect x86 compatibility will bit-rot too.
Limited use of registers in x86 does sound like a good explanation for it being a wash in terms of speed
It seems like there is very little language-level support for small pointers. Only the unreleased Jai language seems to have "relative pointers" (or maybe they took this out)
The Zig compiler recently replaced pointers with integers in their code representation for memory/speed, but lost some type safety in the process -- i.e. a T* isn't a U*, but indices into t[] and u[] are the same type. I'm not sure I like that tradeoff, and it seems like language-level support would help
It definitely _is_ a pain to compile for it.
x32 ABI is not switched on by default on any distro that I'm aware, so you would need to recompile your kernel to get support for it. I think the poor support for it probably is because almost no one is using it. There was even a kernel thread discussing removing support for it.
So, from the point of view of distributing it to end users, x32 ABI is pretty much dead end (for now, *until distros start turning on the flag for it on, for their standard default distribution kernels).
But I would definitely be interested in your results. Most likely, you should see a smaller footprint + a speed boost.