[Win] Remove -DUCHAR_TYPE=wchar_t stopgap and learn to live with char16_t.
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
index e7a1a11..b001b6f 100644 (file)
@@ -1,3 +1,523 @@
+2019-03-06  Ross Kirsling  <ross.kirsling@sony.com>
+
+        [Win] Remove -DUCHAR_TYPE=wchar_t stopgap and learn to live with char16_t.
+        https://bugs.webkit.org/show_bug.cgi?id=195346
+
+        Reviewed by Fujii Hironori.
+
+        * jsc.cpp:
+        (currentWorkingDirectory):
+        (fetchModuleFromLocalFileSystem):
+        * runtime/DateConversion.cpp:
+        (JSC::formatDateTime):
+        Use wchar helpers as needed.
+
+2019-03-06  Mark Lam  <mark.lam@apple.com>
+
+        Fix incorrect handling of try-finally completion values.
+        https://bugs.webkit.org/show_bug.cgi?id=195131
+        <rdar://problem/46222079>
+
+        Reviewed by Saam Barati and Yusuke Suzuki.
+
+        Consider the following:
+
+            function foo() {                        // line 1
+                try {
+                    return 42;                      // line 3
+                } finally {
+                    for (var j = 0; j < 1; j++) {   // line 5
+                        try {
+                            throw '';               // line 7
+                        } finally {
+                            continue;               // line 9
+                        }
+                    }
+                }                                   // line 11
+            }
+            var result = foo();
+
+        With the current (before fix) code base, result will be the exception object thrown
+        at line 7.  The expected result should be 42, returned at line 3.
+
+        The bug is that we were previously only using one set of completion type and
+        value registers for the entire function.  This is inadequate because the outer
+        try-finally needs to preserve its own completion type and value ({ Return, 42 }
+        in this case) in order to be able to complete correctly.
+
+        One might be deceived into thinking that the above example should complete with
+        the exception thrown at line 7.  However, according to Section 13.15.8 of the
+        ECMAScript spec, the 'continue' in the finally at line 9 counts as an abrupt
+        completion.  As a result, it overrides the throw from line 7.  After the continue,
+        execution resumes at the top of the loop at line 5, followed by a normal completion
+        at line 11.
+
+        Also according to Section 13.15.8, given that the completion type of the outer
+        finally is normal, the resultant completion of the outer try-finally should be
+        the completion of the outer try block i.e. { Return, 42 }.
+
+        This patch makes the following changes:
+        
+        1. Fix handling of finally completion to use a unique set of completion
+           type and value registers for each FinallyContext.
+
+        2. Move the setting of Throw completion type to the out of line exception handler.
+           This makes the mainline code slightly less branchy.
+
+        3. Introduce emitOutOfLineCatchHandler(), emitOutOfLineFinallyHandler(), and
+           emitOutOfLineExceptionHandler() to make it clearer that these are not emitting
+           bytecode inline.  Also, these make it clearer when we're emitting a handler
+           for a catch vs a finally.
+
+        4. Allocate the FinallyContext on the stack instead of as a member of the
+           heap allocated ControlFlowScope.  This simplifies its life-cycle management
+           and reduces the amount of needed copying.
+
+        5. Update emitFinallyCompletion() to propagate the completion type and value to
+           the outer FinallyContext when needed.
+
+        6. Fix emitJumpIf() to use the right order of operands.  Previously, we were
+           only using it to do op_stricteq and op_nstricteq comparisons.  So, the order
+           wasn't important.  We now use it to also do op_beloweq comparisons.  Hence,
+           the order needs to be corrected.
+
+        7. Remove the unused CompletionType::Break and Continue.  These are encoded with
+           the jumpIDs of the jump targets instead.
+
+        Relevant specifications:
+        Section 13.15.8: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-try-statement-runtime-semantics-evaluation
+        Section 6.3.2.4: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-updateempty
+
+        * bytecompiler/BytecodeGenerator.cpp:
+        (JSC::FinallyContext::FinallyContext):
+        (JSC::BytecodeGenerator::generate):
+        (JSC::BytecodeGenerator::BytecodeGenerator):
+        (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
+        (JSC::BytecodeGenerator::popFinallyControlFlowScope):
+        (JSC::BytecodeGenerator::emitOutOfLineCatchHandler):
+        (JSC::BytecodeGenerator::emitOutOfLineFinallyHandler):
+        (JSC::BytecodeGenerator::emitOutOfLineExceptionHandler):
+        (JSC::BytecodeGenerator::emitEnumeration):
+        (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
+        (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
+        (JSC::BytecodeGenerator::emitFinallyCompletion):
+        (JSC::BytecodeGenerator::emitJumpIf):
+        (JSC::BytecodeGenerator::emitCatch): Deleted.
+        (JSC::BytecodeGenerator::allocateCompletionRecordRegisters): Deleted.
+        (JSC::BytecodeGenerator::releaseCompletionRecordRegisters): Deleted.
+        * bytecompiler/BytecodeGenerator.h:
+        (JSC::FinallyContext::completionTypeRegister const):
+        (JSC::FinallyContext::completionValueRegister const):
+        (JSC::ControlFlowScope::ControlFlowScope):
+        (JSC::BytecodeGenerator::emitLoad):
+        (JSC::BytecodeGenerator::CompletionRecordScope::CompletionRecordScope): Deleted.
+        (JSC::BytecodeGenerator::CompletionRecordScope::~CompletionRecordScope): Deleted.
+        (JSC::BytecodeGenerator::completionTypeRegister const): Deleted.
+        (JSC::BytecodeGenerator::completionValueRegister const): Deleted.
+        (JSC::BytecodeGenerator::emitSetCompletionType): Deleted.
+        (JSC::BytecodeGenerator::emitSetCompletionValue): Deleted.
+        * bytecompiler/NodesCodegen.cpp:
+        (JSC::TryNode::emitBytecode):
+
+2019-03-06  Saam Barati  <sbarati@apple.com>
+
+        JSScript should keep the cache file locked for the duration of its existence and should truncate the cache when it is out of date
+        https://bugs.webkit.org/show_bug.cgi?id=195186
+
+        Reviewed by Keith Miller.
+
+        This patch makes it so that JSScript will keep its bytecode cache file
+        locked as long as the JSScript is alive. This makes it obvious that it's
+        safe to update that file, as it will only be used in a single VM, across
+        all processes, at a single time. We may be able to extend this in the future
+        if we can atomically update it across VMs/processes. However, we're choosing
+        more restricted semantics now as it's always easier to extend these semantics
+        in the future opposed to having to support the more flexible behavior
+        up front.
+        
+        This patch also:
+        - Adds error messages if writing the cache fails. We don't expect this to
+          fail, but previously we would say we cached it even if write() fails.
+        - Removes the unused m_moduleKey field.
+        - Makes calling cacheBytecodeWithError with an already non-empty cache file fail.
+          In the future, we should extend this to just fill in the parts of the cache
+          that are not present. But we don't have the ability to do that yet, so we
+          just result in an error for now.
+
+        * API/JSScript.mm:
+        (-[JSScript dealloc]):
+        (-[JSScript readCache]):
+        (-[JSScript init]):
+        (-[JSScript writeCache:]):
+        * API/JSScriptInternal.h:
+        * API/tests/testapi.mm:
+        (testCacheFileIsExclusive):
+        (testCacheFileFailsWhenItsAlreadyCached):
+        (testObjectiveCAPI):
+
+2019-03-06  Christopher Reid  <chris.reid@sony.com>
+
+        Followups to (r242306): Use LockHolder instead of std::lock_guard on Remote Inspector Locks
+        https://bugs.webkit.org/show_bug.cgi?id=195381
+
+        Reviewed by Mark Lam.
+
+        Replacing std::lock_guard uses in Remote Inspector with WTF::LockHolder.
+        Also using `= { }` for struct initialization instead of memeset.
+
+        * inspector/remote/RemoteConnectionToTarget.cpp:
+        * inspector/remote/RemoteInspector.cpp:
+        * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
+        * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
+        * inspector/remote/cocoa/RemoteInspectorXPCConnection.mm:
+        * inspector/remote/glib/RemoteInspectorGlib.cpp:
+        * inspector/remote/playstation/RemoteInspectorPlayStation.cpp:
+        * inspector/remote/playstation/RemoteInspectorSocketClientPlayStation.cpp:
+        * inspector/remote/playstation/RemoteInspectorSocketPlayStation.cpp:
+        * inspector/remote/playstation/RemoteInspectorSocketServerPlayStation.cpp:
+
+2019-03-06  Saam Barati  <sbarati@apple.com>
+
+        Air::reportUsedRegisters must padInterference
+        https://bugs.webkit.org/show_bug.cgi?id=195303
+        <rdar://problem/48270343>
+
+        Reviewed by Keith Miller.
+
+        reportUsedRegisters uses reg liveness to eliminate loads/moves into dead
+        registers. However, liveness can report incorrect results in certain 
+        scenarios when considering liveness at instruction boundaries. For example,
+        it can go wrong when an Inst has a LateUse of a register and the following
+        Inst has an EarlyDef of that same register. Such a scenario could lead us
+        to incorrectly say the register is not live-in to the first Inst. Pad
+        interference inserts Nops between such instruction boundaries that cause
+        this issue.
+        
+        The test with this patch fixes the issue in reportUsedRegisters. This patch
+        also conservatively makes it so that lowerAfterRegAlloc calls padInterference
+        since it also reasons about liveness.
+
+        * b3/air/AirLowerAfterRegAlloc.cpp:
+        (JSC::B3::Air::lowerAfterRegAlloc):
+        * b3/air/AirPadInterference.h:
+        * b3/air/AirReportUsedRegisters.cpp:
+        (JSC::B3::Air::reportUsedRegisters):
+        * b3/testb3.cpp:
+        (JSC::B3::testReportUsedRegistersLateUseNotDead):
+        (JSC::B3::run):
+
+2019-03-06  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] AI should not propagate AbstractValue relying on constant folding phase
+        https://bugs.webkit.org/show_bug.cgi?id=195375
+
+        Reviewed by Saam Barati.
+
+        MakeRope rule in AI attempts to propagate the node, which will be produced after constant folding phase runs.
+        This is wrong since we do not guarantee that constant folding phase runs after AI runs (e.g. DFGSpeculativeJIT
+        and FTLLowerDFGToB3 run AI). This results in the bug that the value produced at runtime is different from the
+        proven constant value in AI. In the attached test, AI says the value is SpecStringIdent while the resulted value
+        at runtime is SpecStringVar, resulting in wrong MakeRope code. This patch removes the path propagating the node
+        relying on constant folding phase.
+
+        * dfg/DFGAbstractInterpreterInlines.h:
+        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+
+2019-03-05  Saam barati  <sbarati@apple.com>
+
+        op_switch_char broken for rope strings after JSRopeString layout rewrite
+        https://bugs.webkit.org/show_bug.cgi?id=195339
+        <rdar://problem/48592545>
+
+        Reviewed by Yusuke Suzuki.
+
+        When we did the JSString rewrite, we accidentally broke LLInt's switch_char
+        for rope strings. That change made it so that we always go to the slow path
+        for ropes. That's wrong. The slow path should only be taken when the rope
+        is of length 1. For lengths other than 1, we need to fall through to the
+        default case. This patch fixes this.
+
+        * llint/LowLevelInterpreter32_64.asm:
+        * llint/LowLevelInterpreter64.asm:
+        * runtime/JSString.h:
+
+2019-03-05  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Should check exception for JSString::toExistingAtomicString
+        https://bugs.webkit.org/show_bug.cgi?id=195337
+
+        Reviewed by Keith Miller, Saam Barati, and Mark Lam.
+
+        We missed the exception check for JSString::toExistingAtomicString while it can resolve
+        a rope and throw an OOM exception. This patch adds necessary exception checks. This patch
+        fixes test failures in debug build, reported in https://bugs.webkit.org/show_bug.cgi?id=194375#c93.
+
+        * dfg/DFGOperations.cpp:
+        * jit/JITOperations.cpp:
+        (JSC::getByVal):
+        * llint/LLIntSlowPaths.cpp:
+        (JSC::LLInt::getByVal):
+        * runtime/CommonSlowPaths.cpp:
+        (JSC::SLOW_PATH_DECL):
+
+2019-03-04  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        Unreviewed, build fix for debug builds after r242397
+
+        * runtime/JSString.h:
+
+2019-03-04  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Store bits for JSRopeString in 3 stores
+        https://bugs.webkit.org/show_bug.cgi?id=195234
+
+        Reviewed by Saam Barati.
+
+        This patch cleans up the initialization of JSRopeString fields in DFG and FTL.
+        Previously, we store some part of data separately. Instead, this patch calculates
+        the data first by bit operations and store calculated data with fewer stores.
+
+        This patch also cleans up is8Bit and isSubstring flags. We put them in lower bits
+        of the first fiber instead of the upper 16 bits. Since we only have 3 bit flags, (isRope, is8Bit, isSubstring),
+        we can put them into the lower 3 bits, they are always empty due to alignment.
+
+        * bytecode/AccessCase.cpp:
+        (JSC::AccessCase::generateImpl): A bit clean up of StringLength IC to give a chance of unnecessary mov removal.
+        * dfg/DFGSpeculativeJIT.cpp:
+        (JSC::DFG::SpeculativeJIT::canBeRope):
+        (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
+        (JSC::DFG::SpeculativeJIT::compileMakeRope):
+        * dfg/DFGSpeculativeJIT.h:
+        * ftl/FTLAbstractHeapRepository.cpp:
+        (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
+        * ftl/FTLAbstractHeapRepository.h:
+        * ftl/FTLLowerDFGToB3.cpp:
+        (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
+        (JSC::FTL::DFG::LowerDFGToB3::isRopeString):
+        (JSC::FTL::DFG::LowerDFGToB3::isNotRopeString):
+        * runtime/JSString.cpp:
+        (JSC::JSString::visitChildren):
+        * runtime/JSString.h:
+        (JSC::JSString::is8Bit const):
+        (JSC::JSString::isSubstring const):
+        * tools/JSDollarVM.cpp:
+        (JSC::functionCreateNullRopeString):
+        (JSC::JSDollarVM::finishCreation):
+
+2019-03-04  Joseph Pecoraro  <pecoraro@apple.com>
+
+        ITMLKit Inspector: Data Bindings / Associated Data for nodes
+        https://bugs.webkit.org/show_bug.cgi?id=195290
+        <rdar://problem/48304019>
+
+        Reviewed by Devin Rousso.
+
+        * inspector/protocol/DOM.json:
+
+2019-03-04  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Make Reflect lazily-allocated by dropping @Reflect references from builtin JS
+        https://bugs.webkit.org/show_bug.cgi?id=195250
+
+        Reviewed by Saam Barati.
+
+        By removing @Reflect from builtin JS, we can make Reflect object allocation lazy.
+        We move @ownKeys function from @Reflect to @Object to remove @Reflect reference.
+
+        We also remove m_intlObject field from JSGlobalObject since we no longer use it.
+
+        * builtins/BuiltinNames.h:
+        * builtins/GlobalOperations.js:
+        (globalPrivate.copyDataProperties):
+        (globalPrivate.copyDataPropertiesNoExclusions):
+        * runtime/JSGlobalObject.cpp:
+        (JSC::createReflectProperty):
+        (JSC::JSGlobalObject::init):
+        (JSC::JSGlobalObject::visitChildren):
+        * runtime/JSGlobalObject.h:
+        * runtime/ObjectConstructor.cpp:
+        (JSC::ObjectConstructor::finishCreation):
+        (JSC::objectConstructorOwnKeys):
+        * runtime/ReflectObject.cpp:
+        (JSC::ReflectObject::finishCreation):
+
+2019-03-04  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Offer @makeTypeError instead of exposing @TypeError
+        https://bugs.webkit.org/show_bug.cgi?id=193858
+
+        Reviewed by Mark Lam.
+
+        Instead of exposing @TypeError, we expose @makeTypeError function.
+        And we make TypeError and Error lazily-allocated objects in non JIT environment.
+        In JIT environment, only TypeError becomes lazily-allocated since WebAssembly errors
+        touch Error prototype anyway. But we can make them lazy in a subsequent patch.
+
+        * builtins/AsyncFromSyncIteratorPrototype.js:
+        * builtins/AsyncGeneratorPrototype.js:
+        (globalPrivate.asyncGeneratorEnqueue):
+        * builtins/BuiltinNames.h:
+        * builtins/PromiseOperations.js:
+        (globalPrivate.createResolvingFunctions.resolve):
+        * runtime/JSGlobalObject.cpp:
+        (JSC::JSGlobalObject::initializeErrorConstructor):
+        (JSC::JSGlobalObject::init):
+        (JSC::JSGlobalObject::visitChildren):
+        * runtime/JSGlobalObject.h:
+        (JSC::JSGlobalObject::errorPrototype const):
+        (JSC::JSGlobalObject::errorStructure const):
+        * runtime/JSGlobalObjectFunctions.cpp:
+        (JSC::globalFuncMakeTypeError):
+        * runtime/JSGlobalObjectFunctions.h:
+
+2019-03-04  Carlos Garcia Campos  <cgarcia@igalia.com>
+
+        [GLib] Returning G_TYPE_OBJECT from a constructor does not work
+        https://bugs.webkit.org/show_bug.cgi?id=195206
+
+        Reviewed by Žan Doberšek.
+
+        We are freeing the newly created object before returning from the constructor.
+
+        * API/glib/JSCCallbackFunction.cpp:
+        (JSC::JSCCallbackFunction::construct):
+
+2019-03-02  Darin Adler  <darin@apple.com>
+
+        Retire legacy dtoa function and DecimalNumber class
+        https://bugs.webkit.org/show_bug.cgi?id=195253
+
+        Reviewed by Daniel Bates.
+
+        * runtime/NumberPrototype.cpp:
+        (JSC::numberProtoFuncToExponential): Removed dependency on NumberToStringBufferLength,
+        using NumberToStringBuffer instead. Also tweaked style of implementation a bit.
+
+2019-03-01  Darin Adler  <darin@apple.com>
+
+        Finish removing String::format
+        https://bugs.webkit.org/show_bug.cgi?id=194893
+
+        Reviewed by Daniel Bates.
+
+        * bytecode/CodeBlock.cpp:
+        (JSC::CodeBlock::nameForRegister): Use makeString instead of String::format,
+        using the new "pad" function.
+
+2019-03-01  Christopher Reid  <chris.reid@sony.com>
+
+        [PlayStation] Upstream playstation's remote inspector server
+        https://bugs.webkit.org/show_bug.cgi?id=193806
+
+        Reviewed by Joseph Pecoraro.
+
+        Upstreaming PlayStation's Remote Inspector implementation.
+        It is using a JSON RPC protocol over TCP sockets.
+        This inspector implementation is planned to also support running on a WinCairo Client and Server.
+
+        * PlatformPlayStation.cmake:
+        * SourcesGTK.txt:
+        * SourcesWPE.txt:
+        * inspector/remote/RemoteConnectionToTarget.cpp: Renamed from Source/JavaScriptCore/inspector/remote/glib/RemoteConnectionToTargetGlib.cpp.
+        * inspector/remote/RemoteInspector.h:
+        * inspector/remote/playstation/RemoteInspectorConnectionClient.h: Added.
+        * inspector/remote/playstation/RemoteInspectorConnectionClientPlayStation.cpp: Added.
+        * inspector/remote/playstation/RemoteInspectorMessageParser.h: Added.
+        * inspector/remote/playstation/RemoteInspectorMessageParserPlayStation.cpp: Added.
+        * inspector/remote/playstation/RemoteInspectorPlayStation.cpp: Added.
+        * inspector/remote/playstation/RemoteInspectorServer.h: Added.
+        * inspector/remote/playstation/RemoteInspectorServerPlayStation.cpp: Added.
+        * inspector/remote/playstation/RemoteInspectorSocket.h: Added.
+        * inspector/remote/playstation/RemoteInspectorSocketClient.h: Added.
+        * inspector/remote/playstation/RemoteInspectorSocketClientPlayStation.cpp: Added.
+        * inspector/remote/playstation/RemoteInspectorSocketPlayStation.cpp: Added.
+        * inspector/remote/playstation/RemoteInspectorSocketServer.h: Added.
+        * inspector/remote/playstation/RemoteInspectorSocketServerPlayStation.cpp: Added.
+
+2019-03-01  Saam Barati  <sbarati@apple.com>
+
+        Create SPI to crash if a JSC VM is created
+        https://bugs.webkit.org/show_bug.cgi?id=195231
+        <rdar://problem/47717990>
+
+        Reviewed by Mark Lam.
+
+        * API/JSVirtualMachine.mm:
+        (+[JSVirtualMachine setCrashOnVMCreation:]):
+        * API/JSVirtualMachinePrivate.h:
+        * runtime/VM.cpp:
+        (JSC::VM::VM):
+        (JSC::VM::setCrashOnVMCreation):
+        * runtime/VM.h:
+
+2019-03-01  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Fix FTL build on ARM32_64 by adding stubs for JSRopeString::offsetOfXXX
+        https://bugs.webkit.org/show_bug.cgi?id=195235
+
+        Reviewed by Saam Barati.
+
+        This is a workaround until https://bugs.webkit.org/show_bug.cgi?id=195234 is done.
+
+        * runtime/JSString.h:
+
+2019-03-01  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Use runtime calls for DFG MakeRope if !CPU(ADDRESS64)
+        https://bugs.webkit.org/show_bug.cgi?id=195221
+
+        Reviewed by Mark Lam.
+
+        ARM32_64 builds DFG 64bit, but the size of address is 32bit. Make DFG MakeRope a runtime call not only for DFG 32_64,
+        but also DFG 64 with !CPU(ADDRESS64). This patch unifies compileMakeRope again, and use a runtime call for !CPU(ADDRESS64).
+
+        * dfg/DFGSpeculativeJIT.cpp:
+        (JSC::DFG::SpeculativeJIT::compileMakeRope):
+        * dfg/DFGSpeculativeJIT32_64.cpp:
+        (JSC::DFG::SpeculativeJIT::compileMakeRope): Deleted.
+        * dfg/DFGSpeculativeJIT64.cpp:
+        (JSC::DFG::SpeculativeJIT::compileMakeRope): Deleted.
+
+2019-03-01  Justin Fan  <justin_fan@apple.com>
+
+        [Web GPU] 32-bit builds broken by attempt to disable WebGPU on 32-bit
+        https://bugs.webkit.org/show_bug.cgi?id=195191
+
+        Rubber-stamped by Dean Jackson.
+
+        Dropping support for 32-bit entirely, so I'm intentionally leaving 32-bit broken.
+
+        * Configurations/FeatureDefines.xcconfig:
+
+2019-03-01  Dominik Infuehr  <dinfuehr@igalia.com>
+
+        Fix debug builds with GCC
+        https://bugs.webkit.org/show_bug.cgi?id=195205
+
+        Unreviewed. Fix debug builds in GCC by removing
+        the constexpr-keyword for this function.
+
+        * runtime/CachedTypes.cpp:
+        (JSC::tagFromSourceCodeType):
+
+2019-03-01  Dominik Infuehr  <dinfuehr@igalia.com>
+
+        [ARM] Fix assembler warnings in ctiMasmProbeTrampoline
+        https://bugs.webkit.org/show_bug.cgi?id=195164
+
+        Reviewed by Mark Lam.
+
+        Short branches in IT blocks are deprecated in AArch32. In addition the
+        the conditional branch was the only instruction in the IT block. Short
+        branches are able to encode the condition code themselves, the additional
+        IT instruction is not needed.
+
+        The assembler was also warning that writing into APSR without a bitmask
+        was deprecated. Therefore use APSR_nzcvq instead, this generates the same
+        instruction encoding.
+
+        * assembler/MacroAssemblerARMv7.cpp:
+
 2019-02-28  Tadeu Zagallo  <tzagallo@apple.com>
 
         Remove CachedPtr::m_isEmpty and CachedOptional::m_isEmpty fields
         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::nameForRegister):
 
+2019-02-27  Robin Morisset  <rmorisset@apple.com>
+
+        DFG: Loop-invariant code motion (LICM) should not hoist dead code
+        https://bugs.webkit.org/show_bug.cgi?id=194945
+        <rdar://problem/48311657>
+
+        Reviewed by Saam Barati.
+
+        * dfg/DFGLICMPhase.cpp:
+        (JSC::DFG::LICMPhase::run):
+
 2019-02-27  Antoine Quint  <graouts@apple.com>
 
         Support Pointer Events on macOS