444598 - Need a better approach to abc->IL conversion

Status: RESOLVED FIXED

(Tamarin Graveyard :: Tracing Virtual Machine, defect)

Description

[Tommy Reilly]

There's a lot of potential for optimizing the VM by doing clever things in the abc->IL conversion step.  The approach we have today is to just have highlevel EXTERN's for all abc opcodes is nice and simple but less than ideal.  Nothing the Verifier knows about the code (types) or the code emitter knows about our IL can be utilized.   A trivial example is comparing a String to null (ie OP_pushnull/OP_ifstrictne) resulting in:
                              
  global/flash.internal::checkNull()+11   OP_pushnull                          
  global/flash.internal::checkNull()+12   OP_ifstrictne                        
  code_pool+4305      BR -3485=k_code_pool+821            
  code_pool+821       op__2boxtype_plus_0000              
  code_pool+822       CASE                                
  code_pool+7522      CASE                                
  code_pool+7818      op_DROP_DROP_LIT0                   
  code_pool+7819      EXIT                    

Where a simple "0 =" would have been faster and made for smaller IL.   So how do we translate abc into IL more optimally.  superwording and x86 IL are great but I think a smarter translator are needed.  Any improvements in the IL will result in better traced code as well. 

Goals are:

1) small IL, we want to approach 1 on the abc::IL ratio
2) fast IL, all Verifier knowledge and IL capability should be taken advantage of to produce optimal IL.
3) fast translation, ideally we translate entire methods in the Verifier pass very quickly just like today only much better code comes out, although if a more expensive system results in a net win for performance its okay.

This is a big feature/bug, mostly creating it to track commentary/ideas.

Comment 1

[Edwin Smith]

we can attack this in increments:

- peephole:  works pretty good, but the patterns we'd check for start adding up so there should be a good way to organize the code

- since stack machine bytecode is serialized expression trees, you can get pretty far with a greedy matcher automaton (like a regex matcher).  google for DBURG for an example where bytecode tree patterns are matched by an automaton built from a tree grammer

- crib from MIR: two passes, build expression trees and perform copy/constant propagation and cse in one pass, then emit code in two passes.  the cost of this is it destroys the stack-nature of the code... emitting register-based code is straightforward, just like MIR's second pass.  emitting stack code is doable but would require a redesigned second pass -- CSE and copy propagation makes the expression trees into expression dags which complicates emitting stack machine code 

Comment 2

[Tommy Reilly]

Attachment: some optimizations that proved affective for a large Flex app

Comment 3

[Tommy Reilly]

Instead of more peephole optimizations like this I think a good next step would be to use GlobalOptimizer's data structures to analyze expression trees in a large flex app.  Are there a few very common things we should optimize or is there a ton of variabilty that wants something more sophisticated than peephole.

Comment 4

[Steven Johnson]

Comment on attachment 329511 [details] [diff] [review]
some optimizations that proved affective for a large Flex app

Looks good to me, but you should probably get Edwin to review+ it too -- he know the details of IL better than I

Comment 5

[Edwin Smith]

in Verifier.cpp is "delete mi2" safe?  does buildMethodInfoFor(env) always return a new object?

in vm.fs OP_callstatic_only, it's a good idea to factor out shared code even if it will be inlined back together either by fc.py or the tracer.  

is dump_prim_use() leaving any scalpels in the patient?  not at first glance, just want to be sure.

Comment 6

[Tommy Reilly]

Attachment: abc->IL peephole opts and some misc others

Optimized prereap to mark only active part of stack
Refactored how we deal with MethodInfo's so they are always stack allocated.
Refactored code for needs arg coersion

Comment 7

[Edwin Smith]

Comment on attachment 329684 [details] [diff] [review]
abc->IL peephole opts and some misc others

state.sp and state.rp tell you where the current top of stack is, why not just use those?

Comment 8

[Tommy Reilly]

Tried that and things got really crashy.  Does the tracer really update state.sp?  I thought we'd need to push it out beyond max_local/max_scope b/c the tracer just writes to the stack and doesn't keep it up to date, remember DRC can happen at any object allocation.

Comment 9

[Edwin Smith]

oic, no the trace doesn't keep currentState.sp/rp up to date.  it doesn't keep currentState.f fresh either, afaik.  it could if we knew which calls could invoke the gc, however.

trying to estimate where the active part of the stack top is, however, won't work either -- you don't know how far deep the call is, that triggered the gc run.  could be several stack frames deep.

Comment 10

[Edwin Smith]

one solution could be to insert gc safe points on the trace, where we flush out
currentState and let the gc do its thing, if it wants to.

Comment 11

[Tommy Reilly]

Attachment: Scratch prereap optimizations, now just abc->IL and MethodInfo refactoring

Now just looking for review of MethodInfo changes...

Comment 12

[Steven Johnson]

Comment on attachment 329695 [details] [diff] [review]
Scratch prereap optimizations, now just abc->IL and MethodInfo refactoring

(1) could we add a comment to prereap indicating why the code is commented out?

(2) it looks like some (but not all) of my TraitsData-leak-fix is included in this (the m_tdref stuff in TraitsEnv), did you mean to include it?

Comment 13

[Tommy Reilly]

The comented out code is gone, I made a bug for fixing prereap, I'll regenerate the patch on top of your traits fix when it lands.

Comment 14

[Steven Johnson]

traits fix landed this afternoon

Comment 15

[Tommy Reilly]

pushed in 505:57e806aa856d

Comment 16

[Tommy Reilly]

the wordcode stuff addresses this need nicely.