거짓말 장이가 되시겠군요 ㅋㅋ.
전역변수 형태로 static 하게 가서, stack을 확보하는 시간을 줄인다는 취지는
분명 잘못된 것이 아니지만,
원거리 주소의 변수를 사용하는 것은 근거리 주소의 변수를 사용하는 것에 비해 느립니다.
루핑을 심하게 하는 경우라면 지역변수가 더 빠르죠.
즉, 큰 덩어리를 수시로 할당해야 하는 경우가 아니라면 전역변수를 남용하는게
메모리 사용량을 늘리고, 컴파일 타임(처리할 전역 심볼이 늘어나므로)과 실행시간에 부하를 주게 됩니다.
물론 함수 단위의 모듈성도 떨어지게 되죠.
(이말을 스택의 주소가 스태틱영역의 주소보다 코드부에 더 가깝다는 말로 곡해하시면 곤란합니다.
적어도 스택 포인터 레지스터(SP) 메카니즘은 항상 스택에 생성된 녀석들과 가까운 위치에 있단겁니다)

반복문의 확장은, 많은 개발자들에게 상당히 유효한 최적화 방법으로 알려져 있습니다.
그러나, 이 경우에도 반복문을 무조건 확장하는게 아니라, 매 회 확장시 마다 점프 처리가 필요한 경우라면
코드 량만 늘어나고, 참조해야 할 주소폭이 확장되어 바이너리만 커지는 경우가 발생할 수도 있지요.
또한 컴파일러의 최적화 루틴을 타지 못하게 될 수도 있습니다.

(정수형)곱셈 나눗셈도, 펜티엄 이상에선 대체적으로 1사이클에 수행됩니다.
즉, 예전 도스시절처럼 x * 640 을 절약하기 위해 (x << 9) + (x << 7) 을 사용하는 (512x + 128x = 640x죠)
식의 최적화 역시 해가 됩니다.
물론, 특정 모바일 프로세서등에선 아직 효과가 있고, CPU내부의 부하를 줄임으로 열 발생이나
배터리 소모를 최적화 한다는 취지라면 것도 나쁘지 않습니다.
실수형 최적화를 위해 정수형으로 바꾸고 부동소수점 트릭을 사용한다. 식의 최적화면 Good 이긴합니다.
것도 부호연산이나 지수부와 가수부 데이타를 뜯어내는 정도에 한정되지만요.

어줍잖게 어셈블리를 남용한다. 이것도 문제가 됩니다.
즉, memcpy와 같은 반복 루틴을 최적화 해 보겠다고
asm{
mov edi, tgt     // 혹은 lds
mov esi, src   // 마찬가지
mov ecx, count
rep stosb // 혹은 stosw, stosd...
}
한 것이, for문 한줄을 사용해 최적화 컴파일한 결과보다 느릴 수 있습니다.
  
최적화를 논하기 위해선 공부를 많이 하셔야할 듯 합니다.
아는 지식이 실제 근거 있는 지식이라 하더라도, 적용되는 경우가 아닌 때엔 독이 될 수 있지요.

다소 문제제기만 한 것 같군요.
요약하자면 이렇습니다.
1. 모르면 컴파일러를 믿으세요.
2. 단순 공식같은 최적화 Paradigm은 적용되지 않는 최적화가 많습니다. 최적화가 필요하다면,
   Debug 타임, Release 타임을 구분해 테스트 하며 반드시 RDTSC 명령으로 실제 수행 클럭을
   세어보시기 바랍니다.
3. 더 큰것 부터 최적화 하세요.