DFG::CFGSimplificationPhase::keepOperandAlive() conflates liveness and availability
https://bugs.webkit.org/show_bug.cgi?id=108580

Reviewed by Oliver Hunt.
        
This is a harmless bug in that it only results in us keeping a bit too many things
for OSR.  But it's worth fixing so that the code is consistent.

keepOperandAlive() is called when block A has a branch to blocks B and C, but the
A->B edge is proven to never be taken and we want to optimize the code to have A
unconditionally jump to C.  In that case, for the purposes of OSR, we need to
preserve the knowledge that the state that B expected to be live incoming from A
ought still to be live up to the point of where the A->B,C branch used to be.  The
way we keep things alive is by using the variablesAtTail of A (i.e., we use the
knowledge of in what manner A made state available to B and C).  The way we choose
which state should be kept alive ought to be chosen by the variablesAtHead of B
(i.e. the things B says it needs from its predecessors, including A), except that
keepOperandAlive() was previously just using variablesAtTail of A for this
purpose.
        
The fix is to have keepOperandAlive() use both liveness and availability in its
logic. It should use liveness (i.e. B->variablesAtHead) to decide what to keep
alive, and it should use availability (i.e. A->variablesAtTail) to decide how to
keep it alive.
        
This might be a microscopic win on some programs, but it's mainly intended to be
a code clean-up so that I don't end up scratching my head in confusion the next
time I look at this code.

* dfg/DFGCFGSimplificationPhase.cpp:
(JSC::DFG::CFGSimplificationPhase::keepOperandAlive):
(JSC::DFG::CFGSimplificationPhase::jettisonBlock):
(JSC::DFG::CFGSimplificationPhase::mergeBlocks):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@141544 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Editor::m_compositionNode not updated on HTMLInputElement::setValue()
https://bugs.webkit.org/show_bug.cgi?id=107737

Patch by Aurimas Liutikas <aurimas@chromium.org> on 2013-01-31
Reviewed by Ryosuke Niwa.

Source/WebCore:

Chromium has a bug where the IME composition did not get cancelled on JavaScript changes
to the focused editing field. Most of other WebKit ports were already doing this check
in their EditorClient::respondToChangedSelection. I took that logic and moved it to the
Editor so every port and use the same code.

An existing test editing/input/setting-input-value-cancel-ime-composition.html covers this change.
This test used to have an expectation to fail on Chromium and after this patch it will start passing.

* editing/Editor.cpp:
(WebCore::Editor::cancelCompositionIfSelectionIsInvalid):
    Adding a call that can be used by any the port to cancel the composition if it's no longer valid.
(WebCore):
* editing/Editor.h:
(Editor):

Source/WebKit/chromium:

* public/WebViewClient.h:
(WebKit::WebViewClient::didCancelCompositionOnSelectionChange):
    Adding a callback to let the WebViewClient know that the composition has been cancelled.
* src/EditorClientImpl.cpp:
(WebKit::EditorClientImpl::respondToChangedSelection):
    Adding a call composition if it is no longer valid.

Source/WebKit/efl:

* WebCoreSupport/EditorClientEfl.cpp:
(WebCore::EditorClientEfl::respondToChangedSelection):
    Adding a call to the newly refactored method.

Source/WebKit/gtk:

* WebCoreSupport/EditorClientGtk.cpp:
(WebKit::EditorClient::respondToChangedSelection):
    Adding a call to the newly refactored Editor method.

Source/WebKit/mac:

* WebView/WebHTMLView.mm:
(-[WebHTMLView _updateSelectionForInputManager]):

Source/WebKit/win:

* WebView.cpp:
(WebView::updateSelectionForIME):
    Adding a call to the newly refactored method.

LayoutTests:

* platform/chromium/TestExpectations: Removed fail expectation for the editing/input/setting-input-value-cancel-ime-composition.html since this patch fixes the bug https://bugs.webkit.org/show_bug.cgi?id=55560

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@141545 268f45cc-cd09-0410-ab3c-d52691b4dbfc