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

[Jay K]

I'm thinking m3back could use multiple passes.

 


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

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100331/13ff5b35/attachment-0001.html>