Refactor MacroAssembler interfaces to differentiate the pointer operands from the 64-bit integer operands
https://bugs.webkit.org/show_bug.cgi?id=99154

Reviewed by Gavin Barraclough.

In current JavaScriptCore implementation for JSVALUE64 platform (i.e.,
the X64 platform), we assume that the JSValue size is same to the
pointer size, and thus EncodedJSValue is simply type defined as a
"void*". In the JIT compiler, we also take this assumption and invoke
the same macro assembler interfaces for both JSValue and pointer
operands. We need to differentiate the operations on pointers from the
operations on JSValues, and let them invoking different macro
assembler interfaces. For example, we now use the interface of
"loadPtr" to load either a pointer or a JSValue, and we need to switch
to using "loadPtr" to load a pointer and some new "load64" interface
to load a JSValue. This would help us supporting other JSVALUE64
platforms where pointer size is not necessarily 64-bits, for example
x32 (bug #99153).

The major modification I made is to introduce the "*64" interfaces in
the MacroAssembler for those operations on JSValues, keep the "*Ptr"
interfaces for those operations on real pointers, and go through all
the JIT compiler code to correct the usage.

This is the first part of the work, i.e, to add the *64 interfaces to
the MacroAssembler.

* assembler/AbstractMacroAssembler.h: Add the Imm64 interfaces.
(AbstractMacroAssembler):
(JSC::AbstractMacroAssembler::TrustedImm64::TrustedImm64):
(TrustedImm64):
(JSC::AbstractMacroAssembler::Imm64::Imm64):
(Imm64):
(JSC::AbstractMacroAssembler::Imm64::asTrustedImm64):
* assembler/MacroAssembler.h: map <foo>Ptr methods to <foo>64 for X86_64.
(MacroAssembler):
(JSC::MacroAssembler::peek64):
(JSC::MacroAssembler::poke):
(JSC::MacroAssembler::poke64):
(JSC::MacroAssembler::addPtr):
(JSC::MacroAssembler::andPtr):
(JSC::MacroAssembler::negPtr):
(JSC::MacroAssembler::orPtr):
(JSC::MacroAssembler::rotateRightPtr):
(JSC::MacroAssembler::subPtr):
(JSC::MacroAssembler::xorPtr):
(JSC::MacroAssembler::loadPtr):
(JSC::MacroAssembler::loadPtrWithAddressOffsetPatch):
(JSC::MacroAssembler::loadPtrWithCompactAddressOffsetPatch):
(JSC::MacroAssembler::storePtr):
(JSC::MacroAssembler::storePtrWithAddressOffsetPatch):
(JSC::MacroAssembler::movePtrToDouble):
(JSC::MacroAssembler::moveDoubleToPtr):
(JSC::MacroAssembler::comparePtr):
(JSC::MacroAssembler::testPtr):
(JSC::MacroAssembler::branchPtr):
(JSC::MacroAssembler::branchTestPtr):
(JSC::MacroAssembler::branchAddPtr):
(JSC::MacroAssembler::branchSubPtr):
(JSC::MacroAssembler::shouldBlindDouble):
(JSC::MacroAssembler::shouldBlind):
(JSC::MacroAssembler::RotatedImm64::RotatedImm64):
(RotatedImm64):
(JSC::MacroAssembler::rotationBlindConstant):
(JSC::MacroAssembler::loadRotationBlindedConstant):
(JSC::MacroAssembler::move):
(JSC::MacroAssembler::and64):
(JSC::MacroAssembler::store64):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::shouldBlindForSpecificArch):
(MacroAssemblerX86Common):
(JSC::MacroAssemblerX86Common::move):
* assembler/MacroAssemblerX86_64.h: Add the <foo>64 methods for X86_64.
(JSC::MacroAssemblerX86_64::branchAdd32):
(JSC::MacroAssemblerX86_64::add64):
(MacroAssemblerX86_64):
(JSC::MacroAssemblerX86_64::and64):
(JSC::MacroAssemblerX86_64::neg64):
(JSC::MacroAssemblerX86_64::or64):
(JSC::MacroAssemblerX86_64::rotateRight64):
(JSC::MacroAssemblerX86_64::sub64):
(JSC::MacroAssemblerX86_64::xor64):
(JSC::MacroAssemblerX86_64::load64):
(JSC::MacroAssemblerX86_64::load64WithAddressOffsetPatch):
(JSC::MacroAssemblerX86_64::load64WithCompactAddressOffsetPatch):
(JSC::MacroAssemblerX86_64::store64):
(JSC::MacroAssemblerX86_64::store64WithAddressOffsetPatch):
(JSC::MacroAssemblerX86_64::move64ToDouble):
(JSC::MacroAssemblerX86_64::moveDoubleTo64):
(JSC::MacroAssemblerX86_64::compare64):
(JSC::MacroAssemblerX86_64::branch64):
(JSC::MacroAssemblerX86_64::branchTest64):
(JSC::MacroAssemblerX86_64::test64):
(JSC::MacroAssemblerX86_64::branchAdd64):
(JSC::MacroAssemblerX86_64::branchSub64):
(JSC::MacroAssemblerX86_64::branchPtrWithPatch):
(JSC::MacroAssemblerX86_64::storePtrWithPatch):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131426 268f45cc-cd09-0410-ab3c-d52691b4dbfc
MIPS assembler coding-style fix.
https://bugs.webkit.org/show_bug.cgi?id=99359

Patch by Balazs Kilvady <kilvadyb@homejinni.com> on 2012-10-16
Reviewed by Oliver Hunt.

Coding style fix of existing MIPS assembler header files.

* assembler/MIPSAssembler.h:
(JSC::MIPSAssembler::addiu):
(JSC::MIPSAssembler::addu):
(JSC::MIPSAssembler::subu):
(JSC::MIPSAssembler::mul):
(JSC::MIPSAssembler::andInsn):
(JSC::MIPSAssembler::andi):
(JSC::MIPSAssembler::nor):
(JSC::MIPSAssembler::orInsn):
(JSC::MIPSAssembler::ori):
(JSC::MIPSAssembler::xorInsn):
(JSC::MIPSAssembler::xori):
(JSC::MIPSAssembler::slt):
(JSC::MIPSAssembler::sltu):
(JSC::MIPSAssembler::sltiu):
(JSC::MIPSAssembler::sll):
(JSC::MIPSAssembler::sllv):
(JSC::MIPSAssembler::sra):
(JSC::MIPSAssembler::srav):
(JSC::MIPSAssembler::srl):
(JSC::MIPSAssembler::srlv):
(JSC::MIPSAssembler::lbu):
(JSC::MIPSAssembler::lw):
(JSC::MIPSAssembler::lwl):
(JSC::MIPSAssembler::lwr):
(JSC::MIPSAssembler::lhu):
(JSC::MIPSAssembler::sb):
(JSC::MIPSAssembler::sh):
(JSC::MIPSAssembler::sw):
(JSC::MIPSAssembler::addd):
(JSC::MIPSAssembler::subd):
(JSC::MIPSAssembler::muld):
(JSC::MIPSAssembler::divd):
(JSC::MIPSAssembler::lwc1):
(JSC::MIPSAssembler::ldc1):
(JSC::MIPSAssembler::swc1):
(JSC::MIPSAssembler::sdc1):
(MIPSAssembler):
(JSC::MIPSAssembler::relocateJumps):
(JSC::MIPSAssembler::linkWithOffset):
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::add32):
(JSC::MacroAssemblerMIPS::and32):
(JSC::MacroAssemblerMIPS::sub32):
(MacroAssemblerMIPS):
(JSC::MacroAssemblerMIPS::load8):
(JSC::MacroAssemblerMIPS::load32):
(JSC::MacroAssemblerMIPS::load32WithUnalignedHalfWords):
(JSC::MacroAssemblerMIPS::load16):
(JSC::MacroAssemblerMIPS::store8):
(JSC::MacroAssemblerMIPS::store16):
(JSC::MacroAssemblerMIPS::store32):
(JSC::MacroAssemblerMIPS::nearCall):
(JSC::MacroAssemblerMIPS::test8):
(JSC::MacroAssemblerMIPS::test32):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131427 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Separate WebKit2 instances use the same local storage
https://bugs.webkit.org/show_bug.cgi?id=89666

Patch by Szilard Ledan <szledan@inf.u-szeged.hu> on 2012-10-16
Reviewed by Simon Hausmann.

Source/WebKit2:

For multi-threaded (parallel) testing, WTRs must not write into the same directory.
To avoid that, results need to be stored in the location defined by DUMPRENDERTREE_TEMP
environment variable that is created by NRWT. To do that, WebContext needed to be
extended with diskCacheDirectory and cookieStorageDirectory APIs.

* Shared/WebProcessCreationParameters.cpp:
(WebKit::WebProcessCreationParameters::encode):
(WebKit::WebProcessCreationParameters::decode):
* Shared/WebProcessCreationParameters.h:
(WebProcessCreationParameters):
* UIProcess/API/C/WKContext.cpp:
(WKContextSetDiskCacheDirectory):
(WKContextSetCookieStorageDirectory):
* UIProcess/API/C/WKContextPrivate.h:
* UIProcess/WebContext.cpp:
(WebKit::WebContext::createNewWebProcess):
(WebKit::WebContext::diskCacheDirectory):
(WebKit):
(WebKit::WebContext::cookieStorageDirectory):
* UIProcess/WebContext.h:
(WebKit::WebContext::setDiskCacheDirectory):
(WebKit::WebContext::setCookieStorageDirectory):
(WebContext):
* UIProcess/efl/WebContextEfl.cpp:
(WebKit::WebContext::platformDefaultDiskCacheDirectory):
(WebKit):
(WebKit::WebContext::platformDefaultCookieStorageDirectory):
* UIProcess/gtk/WebContextGtk.cpp:
(WebKit::WebContext::platformDefaultDiskCacheDirectory):
(WebKit):
(WebKit::WebContext::platformDefaultCookieStorageDirectory):
* UIProcess/mac/WebContextMac.mm:
(WebKit::WebContext::platformInitializeWebProcess):
(WebKit):
(WebKit::WebContext::platformDefaultDiskCacheDirectory):
(WebKit::WebContext::platformDefaultCookieStorageDirectory):
* UIProcess/qt/WebContextQt.cpp:
(WebKit):
(WebKit::WebContext::platformDefaultDiskCacheDirectory):
(WebKit::WebContext::applicationCacheDirectory):
(WebKit::WebContext::platformInitializeWebProcess):
(WebKit::WebContext::platformDefaultCookieStorageDirectory):
* UIProcess/win/WebContextWin.cpp:
(WebKit::WebContext::platformInitializeWebProcess):
(WebKit::WebContext::platformDefaultDiskCacheDirectory):
(WebKit):
(WebKit::WebContext::platformDefaultCookieStorageDirectory):
* WebProcess/mac/WebProcessMac.mm:
(WebKit::WebProcess::platformInitializeWebProcess):
* WebProcess/win/WebProcessWin.cpp:
(WebKit::WebProcess::platformInitializeWebProcess):

Tools:

TestController has been modified to get the local storage from
DUMPRENDERTREE_TEMP environment variable. If it's undefined
then it works with the default directory. The aim is for the parallelly
started WTRs to use separate directories. It was implemented for WK1
long time ago and it works fine.

* WebKitTestRunner/TestController.cpp:
(WTR::TestController::initialize):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131428 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Chromium] Unreviewed gardening, TestExpectations updated.

* platform/chromium/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131431 268f45cc-cd09-0410-ab3c-d52691b4dbfc
hb_face_t instances should not depend on FontPlatformData
https://bugs.webkit.org/show_bug.cgi?id=99430

Reviewed by Kent Tamura.

Use platform specific font data (e.g. SkTypeface) to get
font tables for harfbuzz-ng.

No new tests. No changes in behavior.

* platform/graphics/harfbuzz/ng/HarfBuzzNGFaceCairo.cpp:
(WebCore::harfbuzzCairoGetTable): Takes cairo_scaled_font_t* as userData.
(WebCore::HarfBuzzNGFace::createFace):
* platform/graphics/harfbuzz/ng/HarfBuzzNGFaceCoreText.cpp:
(WebCore::harfbuzzCoreTextGetTable): Takes CGFontRef as userData.
(WebCore::HarfBuzzNGFace::createFace):
* platform/graphics/harfbuzz/ng/HarfBuzzNGFaceSkia.cpp:
(WebCore::harfbuzzSkiaGetTable): Takes SkFontID as userData.
(WebCore::HarfBuzzNGFace::createFace):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131432 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Fix some appearance glitches of multiple fields input elements
https://bugs.webkit.org/show_bug.cgi?id=99412

A follow-up change for r131421.

* css/themeWin.css:
(input[type="text"]): Don't reset paddings for date/time types.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131433 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add test that checks that reloading after setting a value for an input element from a suggestion picker resets the values
https://bugs.webkit.org/show_bug.cgi?id=99407

Reviewed by Kent Tamura.

We want to test that a reload resets values of input elements, even if
they were set by the suggestion picker.

* platform/chromium/fast/forms/suggestion-picker/date-suggestion-picker-reset-value-after-reload-expected.txt: Added.
* platform/chromium/fast/forms/suggestion-picker/date-suggestion-picker-reset-value-after-reload.html: Added.


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