[M3devel] changing m3middle/m3back to have multiple passes?

[Rodney M. Bates]

Jay K wrote:
> I'm thinking m3back could use multiple passes.

This would be a big reversal of the fundamental design philosophy of this
back end.  Its primary design criterion was to be simple and fast.  That
means single-pass.  There have been several compilers (often whole compilers,
not just code generators) written to this principle.  For some purposes,
it is a good thing.

This, of course, inevitably means the generated code is not as small/fast
as it could be.  It's part of the trade off.  We have two points on this
trade off scale now.  I think we want to keep the one-pass code generator.
If you change it, at least make a branch and keep the original design
easily accessible.


>  
> 
> There a few reasons, things that would be easier/possible if it had them.
>  
> 
> I know adding passes will slow it down, but I suspect it will still be
> about as pleasantly fast as it is now.
>  
>  
> The optimizations I have in mind:
>   inlining, including where function definitions come after the call
>     I think inlining where the "small" functions come first is doable in 
> pass,
>     but not if uses come before calls.
>  
> 
>   not saving unused registers
>     This only a small optimization and could probably be done in one
>     pass if m3objfile got a "memmove" operation. Well, I already
>     have the optimization in somewhat, but it involves nop-ing out
>     code instead of removing it completely.
>  
> 
>   dead store removal, and then removing the resulting dead code to 
> compute the value
> 
>  
>   possibly better register allocation -- e.g. based on noticing which
>    variables are used often, or based on how they are used, for example
>    if a variable (or expression/temporary) ends serving a shift count,
>    we should favor putting it in ecx up front, instead of moving it to
>    ecx later, but we don't generally know this till too late
>  
>  
> As I understand, m3middle already has the notion of "recording"
>  and "playing back" calls to the M3CG interface.
>   That seems like a good starting point?
>  
> 
> Some optimizations can be made via "CG to CG" transforms.
>  
> 
> However I think in general I think the required design would include:
>  - ability to add in "private operations"; maybe
>  - ability to add "private data" to existing operations
>    A very simple one is annotate functions with required frame size.
>    This isn't currently known until the end of the function.
>  - clearly, ability to remove operations
>  
> 
> Can/should we somehow augment m3middle in support of this line of thinking?
>  
> 
> Or is that just not the way to go?
> Each backend should have its own internal representation and loop over it?
> 
>  - Jay
>