[Info-vax] x86-64 VMS executable image sizes and memory requirements ?

[already5chosen at yahoo.com]

On Sunday, December 22, 2019 at 6:07:21 PM UTC+2, John Reagan wrote:
> On Sunday, December 22, 2019 at 6:13:50 AM UTC-5, already... at yahoo.com wrote:
>  
> > Quite possibly, DEC C vs clang is just one of the reasons.
> > Another reason could be register allocation. When you have only 16 registers then good register allocation is very important no only for speed, but for a code size as well. It is much less critical when you have 32 registers. In the later case, I'd imagine that any allocator which is not completely idiotic, will give about the same code size (but not the same speed).
> 
> 16?  I wish.  By the time, you avoid the stack pointer, the frame pointer, the base pointer, the 6 argument registers (while doing argument things), non-preserved registers (for things that need to survive across a routine call), etc., XMACRO has about 4-5 to play with at any point in time.
> 

I was talking about C.
In x86-64 C ABI's I am familiar with (Win64 and SysV), majority of the the things you mentioned are optional. Naturally, except stack pointer.


> > 
> > But yes, DEC C and LLVM/clang are probably quite different in that that LLVM/clang takes "don't optimize" command much more literally.
> > In that regard, it is similar to MSVC and gcc.
> > 
> > 
> 
> GEM isn't SSA so even the non-optimized code works about the same # of variables as are in the source file.  LLVM is SSA so the the non-optimized LLVM IR from clang appears to have thousands more variables.  Of of the early LLVM optimizers flattens all of that back out, but not for -O0. 


I didn't realize it.
Considering what you said, my measurements are starting to look favorable to -O0. Probably, in a more typical case it fares even worse.


> You get large stack allocations and lots of data moving back and forth.  Of course, the chip and cache will help (ignoring speculative data leakage) so code size and code speed are still difficult to match up.