[Webkit-unassigned] [Bug 69690] DFG does not have flow-sensitive intraprocedural control flow analysis

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=69690





--- Comment #29 from Filip Pizlo <fpizlo at apple.com>  2011-10-10 12:31:43 PST ---
(In reply to comment #28)
> > I know.  I don't think I want to do this in this patch, but I think I've got a solution for both this and register allocation: have named speculations (so just as we have an enum of node types, have an enum of speculation types), have attributes on nodes that describe what speculatiuons should be performed, have one phase in Propagator that deduces what those speculatins ought to be, and then while we're at it, have node attributes that specify what additional registers the codegen for a node will required.  And viola, we'll be able to do global register allocation and get rid of GenerationInfo entirely.
> 
> Not sure if this helps, but another possible option is to add explicit nodes for each speculation. We didn't do this originally because it made the graph not reusable for the non-speculative path, but now there is no non-speculative path.

This would be a performance regression.  Our boolean speculations are done as part of testing the boolean, and often without using SpeculateBooleanOperand.  And then we have tests for object-or-undefined-or-null, where the speculation checks are embedded in the control flow of the node itself.

As the DFG gets more powerful, our nodes will have more sophisticated execution semantics, and our optimizations will have to have more sophisticated modeling of those execution semantics.  Better to just live with it.  I've seen compiler hackers go down the path of trying to modularize this aspect of compilation and the results are invariably uglier than what we have.  You either have to introduce new opcodes for each micro operation, but then you get performance regressions unless you also introduce more basic blocks (we could model the object-or-undefined speculation by blowing each node that does that into a control flow diamond).  Or you can start to create a formal specification for your nodes.  But that fails because the formal specification becomes more hairy and complicated than the compiler you were going to write in the first place.

> 
> > > > +    static inline BlockIndex getBytecodeBegin(OwnPtr<BasicBlock>* block)
> > > > +    {
> > > > +        return (*block)->bytecodeBegin;
> > > > +    }
> 
> RE this vs binarySearch, perhaps the binarySearch template could be modified to pass T& instead of T* to child functions.

That would still make the style bot unhappy...

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.