On Mon, May 7, 2012 at 9:26 PM, Charles Oliver Nutter
<head...@headius.com>wrote:
> Looks good so far reading the ast --ir output. A few things on which I
> could use clarification:
>
> * Binding variable load/stores are unconditionally done before/after
> block calls, yes? Opportunity to optimize or failover to all binding
> variables if we see there's a lot of churn?
>
For the full logic, look at 'applyTransferFunction' in
dataflow/analyses/StoreLocalVarPlacementNode.java ... this is the analysis
phase. addStores which mirrors that function does the actual placement. I
have tried to document it reasonably, but it could still be a little
cryptic. But, it tries to account for blocks, exceptions, global-var
tracing, and thread concurrency.
* Stores of only those vars that are "dirty" (modified but not yet spilled
into binding). The logic is delay as far as possible to store -- so if you
modify a variable multiple times before it needs to be stored, you'll avoid
all the intermediate stores. Calls / instructions that are barriers
(either because the instr. can effectively look at all binding vars) force
all currently dirty vars to be spilled. Similarly for loads.
So, this logic does not add any loads/stores in fib_ruby or in
red_black_tree benchmarks, for example. Because of this, the
AddCallProtocolInstructions also does not add push/pop binding instructions
because it is not needed there. But, if you look at bench_richards, you'll
notice stores/loads as well as push/pop binding instructions.
I am happy to meet you and Tom and go over the generic logic of the
dataflow passes and any logic specific to these passes.
> * Are all variables bound regardless of usage in the block?
> (proc-as-binding, grrr)
>
Only those vars that have modified but not yet spilt will be spilt before
the block-receiving call, but yes, all vars will get a slot in the binding
irrespective of whether block uses them or not.
> * I have not yet looked at the linearized code to see how the ensure
> logic fires. Judging by the output, the normal and exceptional paths
> are already encoded separately, which is how I'd hope to see it.
>
Yes, the push-pop are placed in all exit paths (breaks, returns,
exceptions), adding additional catch-ensure logic as necessary.
> * Depending on how we encode $~ and $_, they could be treated as
> binding locals too.
>
That is correct -- but that is deferred for later.
At the moment I'm going to implement this with the method body
> allocating the DynamicScope *and* doing the push/pop. If we can
> eliminate the need for pushing the scopes onto an external
> thread-local structure (i.e. pass it along call stack, which indy will
> help with)
Right now, I dont add push/pop binding calls for blocks since that is hard
(explicit load/stores are added in all scopes however), so you will have to
continue to implement the implcit push/pop with requisite try/finally
clauses as in the current runtime when you are executing blocks.
I dont assume anything about where DynamicScope resides. I haven't thought
about when we can get away with allocating dyn-scopes on the java call
stack (vs. the heap), but yes, if it can be done, then pops do become nops.
Subbu.
> the pushing, popping, and finally/ensure logic can
> disappear and we'll *just* have the scope allocation (i.e. pop will be
> a no-op). That would definitely be the ideal, since it would allow for
> bindings to eventually escape-analyze away (once we get the JVM to
> inline through to closures).
>
> - Charlie
>
> On Tue, May 8, 2012 at 2:14 AM, Charles Oliver Nutter
> <head...@headius.com> wrote:
> > I will look into this a bit tonight and see if I can get basic binding
> > logic implemented in IR2JVM. Thanks, Subbu!
> >
> > On Mon, May 7, 2012 at 8:48 PM, Subramanya Sastry <sss.li...@gmail.com>
> wrote:
> >> I started working on implementing an explicit call protocol last week.
> >> It required me to clean up a few other bits which I did over several
> commits
> >> since y'day.
> >>
> >> I now committed a first cut at AddExplicitCallProtocolInstructions
> compiler
> >> pass.
> >>
> >> I tested this with the interpreter and it seeks to run fine. There may
> be
> >> bugs in corner cases ... but I haven't run into it running rubyspecs,
> gem
> >> list, and irb.
> >>
> >> To take full advantage of this, you need to run the following 2 passes:
> >> AddLocalVarLoadStoreInstructions, AddExplicitCallProtocolInstructions,
> and
> >> implement compiler code for PushBinding, PopBinding, LoadLocalVar and
> >> StoreLocalVar instructions.
> >>
> >> Ex: jruby -X-CIR
> >>
> -Xir.passes=OptimizeTempVarsPass,LocalOptimizationPass,DeadCodeElimination,AddLocalVarLoadStoreInstructions,AddCallProtocolInstructions,LinearizeCFG
> >> bench/bench_fib_recursive.rb
> >>
> >> Subbu.
> >>
> >> PS: There is one private patch for operands/TemporaryVariable that I
> have
> >> not yet committed -- this has got to do with handling use-before-defs in
> >> Ruby. This is normally not required for tmps but with explicit
> load/store
> >> of local-vars, this becomes necessary since all local vars are now
> pushed
> >> into temp vars (and java local vars in the compiler). This patch is
> >> required for gem list and for getting "green" on rubyspecs, for ex.
> This
> >> only affects the interpreter, not the compiler since I presume you have
> this
> >> logic there anyway. The patch is trivial (enclosed below)
> >>
> >> @Override
> >> public Object retrieve(ThreadContext context, IRubyObject self,
> >> DynamicScope currDynScope, Object[] temp) {
> >> - return temp[offset];
> >> + Object o = temp[offset];
> >> + return o == null ? context.nil : o;
> >> }
> >>
> >> I have not committed this because I was hoping that we could find a way
> to
> >> eliminate this (both here and in DynamicScope.java:getValueOrNil ) by
> >> canonicalizing the instr stream to eliminate use-before-defs in ruby
> code --
> >> I dont yet have a cheap fix for it, so haven't implemented yet, but
> maybe I
> >> should just commit this patch and forget about it for now.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
