> Проблема в том, что стек растёт в обратную сторону относительно обычной памяти
> Т.е, для него изначально выделили отдельный небольшой блок и далее он в
> нём растёт пока не дойдёт до потолка
> И это всё далеко от общего количества ОЗУ

Ну, вообще, реально выделяют страницу или две (если физически), а заказывают столько, сколько считают нужным. Если происходит исключение, то подсистема памяти видит, что физически страница закончилась и выделяет новую.

Для однопоточных программ было следующее распределение памяти (от младших адресов к старшим):

КОД
ДАННЫЕ
КУЧА (растёт вниз)
/свободное место/
СТЕК (растёт в верх)

т.е. для стека можно было указать виртуальный адрес 0x7ffffffc и дальше пусть растёт сколько влезет, единственно, что его будет ограничивать - это куча, которая растёт ему на встречу.

С многопоточными всё стало сложнее. Тем не менее, если необходимо, то есть межанизм заказать столько стека, сколько надо.

В Unix см. https://man7.org/linux/man-pages/man3/pthread_attr_setstack.... и https://man7.org/linux/man-pages/man3/pthread_attr_setstacks...

В Windows - см. https://learn.microsoft.com/en-us/cpp/c-runtime-library/refe...

Тут больше проблема в том, что для многопоточных программ все потоки находятся в одном адресном пространстве, и, в итоге, если сильно постараться, можно налезть и на стек другого потока, и на его данные.

> С другой стороны, тот же LLVM выдаёт промежуточный процессорно-независимый выхлоп, который
> не зависит от регистров и даже архитектуры, а лишь упирается в
> идею бездонного стека. И его там нереально оптимизируют ради.. а чего,
> собственно ?

не совсем, насколько я понимаю, в LLVM используется идея бесконечного числа регистров.