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

[Tony Hosking]

Indeed.  I think we would be better served exploring alternatives like LLVM where we can rely on others to implement the grungy compiler optimisations and we can sail above the fray worrying about the language proper


On 1 Apr 2010, at 10:28, Rodney M. Bates wrote:

> 
> 
> 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