🚀 go-pugleaf

>> Well, there is also actually a strong *hint* that the variable will
>> be heavily *dynamically* used across statement boundaries, in the
>> current scope. The compiler can use this hint very effectively.
>
>Such a hint is only useful to an exceptionally dumb compiler.  Most
>modern compilers do better data flow analysis than human programmers
>are willing to do. Studies have shown that compilers can consistently
>do a _very_ good job of register allocation without such hints.  In fact,
>most C compilers simply ignore the 'register' attribute except to verify
>that the variable is never used with an 'address-of' (&) operator.

Throw in profiling, and you've got a deal.  But very few compilers actually
take profiling data into account, and if you've written a routine which takes
a parameter 'n' that gives the iteration count for the loop, no amount of
static data flow analysis (even interprocedural, in many cases) is going to
tell you the dynamics of that loop.  Now say you have another loop, with a
fixed count of "10".  Which should the optimizer think is going to be more
heavily executed?  A careful programmer can hint to the optimizer with
'register' which variables he thinks are more important, which may be all the
hint the compiler needs.  And often it doesn't take a lot of work to do this,
so you are not "better off using assembly langauge".  There is also
portability to consider.

Now I agree that often, the 'register' attribute is misued by programmers.
So I would suggest a compiler pragma which says something to the effect of
"take my register declarations seriously", and ignorigin them (as usual) by
default.

>Yes, but Pascal is not separately compilable.  The compiler can do a complete
>interprocedural dataflow analysis to find out _unambiguously_ what arguments
>might be aliased with what global variables.

(scoff...)