[Webkit-unassigned] [Bug 84324] DFG can have the spill format identical to the register format

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jun 6 02:06:54 PDT 2012


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





--- Comment #8 from Yuqiang Xian <yuqiang.xian at intel.com>  2012-06-06 02:06:51 PST ---
(In reply to comment #4)
> (From update of attachment 145923 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=145923&action=review
> 
> I'm fine with this on principle, but I'm not sure about the calls to terminateSpeculativeExecution().  These days DFG::AbstractState must know exactly where OSR exits may happen since this information is consumed by store elimination.  Hence, any calls to speculationCheck() and terminateSpeculativeExecution() ought to be guarded by checks against things that AbstractState would know during the CFA phase, to ensure that we don't end up performing store elimination under the assumption that there is no OSR exit only to have an OSR exit inserted by the backend.

I see assertions are planted in terminateSpeculativeExecution()?

> 
> > Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp:1043
> > +    if (isKnownNotInteger(nodeIndex)) {
> > +        terminateSpeculativeExecution(Uncountable, JSValueRegs(), NoNode);
> > +        returnFormat = DataFormatInteger;
> > +        return allocate();
> > +    }
> > +
> 
> Perhaps it's better to use isInt32Prediction(m_state.forNode(nodeIndex).m_type) here?

This might not be true. In this case we want to terminate the speculative execution if we know that the child is definitely *not* an integer (or boolean, cell). Examining the generation info directly may be more straightforward and safe, e.g., if we know the info format is (JS)Cell/(JS)Boolean or (JS)Double, we don't need any speculation check here but just forcing terminate the execution. if we rely on the predictions we may still need to plant a speculation check here.

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



More information about the webkit-unassigned mailing list