[webkit-dev] Windows 32-bit support?
ararunprasad at gmail.com
Wed Jun 26 07:57:06 PDT 2019
I could see that the following comment from
>> We also disable this op_wide16 feature in Windows CLoop, which is used
in AppleWin port. When the code size of
>> CLoop::execute increases, MSVC starts generating CLoop::execute function
with very large stack allocation
>> requirement. Even before introducing this 16bit bytecode, CLoop::execute
in AppleWin takes almost 100KB stack
>> height. After introducing this, it becomes 160KB. While the semantics of
the function is correctly compiled,
>> such a large stack allocation is not essentially necessary, and this
leads to stack overflow errors quite easily,
>> and tests fail with AppleWin port because it starts throwing stack
overflow range error in various places.
>> In this patch, for now, we just disable op_wide16 feature for AppleWin
so that CLoop::execute takes 100KB
>> stack allocation because this patch is not focusing on fixing AppleWin's
CLoop issue. We introduce a new backend
>> type for LLInt, "C_LOOP_WIN". "C_LOOP_WIN" do not generate wide16
version of code to reduce the code size of
>> CLoop::execute. In the future, we should investigate whether this MSVC
issue is fixed in Visual Studio 2019.
>> Or we should consider always enabling ASM LLInt for Windows.
Does that mean high stack usage in Windows is a known issue?
Thanks & Regards,
On Wed, 26 Jun 2019 at 12:10, Arunprasad Rajkumar <ararunprasad at gmail.com>
> Thank you all for your guidance.
> I understand that JIT and LLInt bytecode interpreter is not supported on
> X86(32-bit). The only option I can use is C_LOOP, which have high stack
> usage issue in the latest code. I will continue with my investigation on
> C_LOOP's stack usage.
> Thanks & Regards,
> On Wed, 26 Jun 2019 at 04:13, Yusuke Suzuki <ysuzuki at apple.com> wrote:
>> On Jun 25, 2019, at 9:13 AM, Adrian Perez de Castro <aperez at igalia.com>
>> I was mistaken about one thing (sorry!), please read below...
>> On Tue, 25 Jun 2019 19:01:54 +0300, Adrian Perez de Castro <
>> aperez at igalia.com> wrote:
>> On Tue, 25 Jun 2019 10:42:04 -0500, Michael Catanzaro <
>> mcatanzaro at igalia.com> wrote:
>> It's great that you find our stable branches helpful, but keep in mind
>> those branches do not include Windows-specific fixes.
>> On Tue, Jun 25, 2019 at 9:53 AM, Arunprasad Rajkumar
>> <ararunprasad at gmail.com> wrote:
>> Right. Actually the problem is in 32-bit Windows platform. I see that
>> the JIT support has been dropped some time ago, and CLOOP based
>> backend seems to be unstable on 32-bit Windows. Any thoughts on that?
>> So I'm not an expert here, but I understand there are three ways you
>> can build JSC:
>> (1) -DENABLE_JIT=ON, -DENABLE_C_LOOP=OFF
>> (2) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=OFF (?)
>> (3) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=ON
>> (-DENABLE_JIT=ON and -DENABLE_C_LOOP=ON are incompatible.)
>> I believe that nowadays the only 32-bit platforms supported by JIT are
>> Linux, and there only for ARM and MIPS, not x86. So you're almost
>> certainly going to need to use -DENABLE_JIT=OFF. That eliminates option
>> JIT works on x86 as long as your CPU has support for SSE2 instructions.
>> Oops, this is not quite true: JIT does NOT work on 32-bit x86 at the
>> (The JIT compiler does emit SSE2 instructions, though. When/If the JIT is
>> made to work on 32-bit x86, support for SSE2 will be needed.)
>> WebKit no longer supports non-SSE2 x86 CPUs even without JIT.
>> And I think we are not supporting 32bit Windows x86 JIT. CLoop (AppleWin)
>> is recommended.
>> You say the cloop seems unstable for you, which is option (3). So
>> perhaps you should try option (2) if you haven't already. I'm not
>> actually sure if that works, because I'm not an expert, which is why I
>> added that (?) to it. But at least it couldn't hurt to try.
>> Option (2) would be using the LLint bytecode interpreter, without JIT.
>> In principle CLoop is expected to work “everywhere” because the
>> is generated C/C++ code, which gets then built by the same compiler used
>> build all the rest of WebKit.
>> Maybe the Windows port maintainers know more about the status of 32-bit
>> Windows support?
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev