On 23/06/17 19:55, Michael Catanzaro wrote:
> On Fri, Jun 23, 2017 at 12:36 PM, Yusuke SUZUKI
> wrote:
>> It's middle of 2017! And Debian stable is released.
>>
>> We discussed a bit about updating GCC and MSVC in [1].
>> Based on the comment from JF[1], I think start of
I've just opened the bug for upgrading GCC version.
https://bugs.webkit.org/show_bug.cgi?id=174155
Regards,
Yusuke Suzuki
On Tue, Jun 27, 2017 at 2:21 AM, Olmstead, Don
wrote:
> Same for our WinCairo bots which embed it into a Docker image,
>
On Wed, Jul 5, 2017 at 6:32 AM, Carlos Alberto Lopez Perez
wrote:
I think the default build toolchain should be supported also,
at least without the requirement of "one year after the release".
I propose this change to the policy over yours:
- This policy applies to runtime
Alternatively, the JIT can read the content of these addresses and write them
back as-is
> On Jul 5, 2017, at 09:01, Filip Pizlo wrote:
>
> We should not use those helpers, especially in the JIT. It does not make
> sense for the JIT to emit calls to system functions when
We should not use those helpers, especially in the JIT. It does not make sense
for the JIT to emit calls to system functions when the user is expecting it to
emit an instruction. If we cannot perfectly select the right barrier on a
particular CPU, we should disable concurrency on that CPU.
On Linux you can do the following:
((void(*)())0x0fa0)();
That address contains a helper which does the “right” barrier, including if
you’re not on an SMP system it’ll do nothing.
Details: https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt
2017-07-05 12:41 GMT-03:00 JF Bastien :
> On Linux you can do the following:
>
> ((void(*)())0x0fa0)();
>
>
> That address contains a helper which does the “right” barrier, including if
> you’re not on an SMP system it’ll do nothing.
>
> Details:
>
2017-07-05 18:25 GMT-03:00 Filip Pizlo :
> You need to establish that the JIT is a performance progression over the
> LLInt on ARMv6. I am opposed to more ARMv6 patches landing until there is
> some evidence provided that you’re actually getting speed-ups.
It makes sense. I
To be clear, I’m concerned that the 32-bit JIT backends have such bad tuning
for these embedded platforms that it’s just pure badness. Until you can prove
that you can change this, I think that porting should focus on making the cloop
great. Then, we can rip out support for weird CPUs rather
> On Jul 5, 2017, at 19:19, Caio Lima wrote:
>
> 2017-07-05 12:41 GMT-03:00 JF Bastien :
>> On Linux you can do the following:
>>
>> ((void(*)())0x0fa0)();
>>
>>
>> That address contains a helper which does the “right” barrier, including if
>>
OK, I've just landed GCC upgrade in r219186!
After upgrading Windows MSVC to 2017, we will get full C++14 environment!
Regards,
Yusuke Suzuki
On Thu, Jul 6, 2017 at 12:10 AM, Michael Catanzaro
wrote:
> On Wed, Jul 5, 2017 at 6:32 AM, Carlos Alberto Lopez Perez <
>
What’s the testing plan here? Do y'all plan to add a bot that ensures ARMv6
stays working?
- Saam
> On Jun 13, 2017, at 6:48 PM, Caio Lima wrote:
>
> Hi All.
>
> Some of you guys might know me through the work I have been doing in
> JSC. The experience working with
You need to establish that the JIT is a performance progression over the LLInt
on ARMv6. I am opposed to more ARMv6 patches landing until there is some
evidence provided that you’re actually getting speed-ups.
-Filip
> On Jun 13, 2017, at 6:48 PM, Caio Lima wrote:
>
>
On 05/07/17 23:24, Saam barati wrote:
> What’s the testing plan here? Do y'all plan to add a bot that ensures ARMv6
> stays working?
>
> - Saam
We do.
I will deploy one at https://build-webkit.igalia.com/waterfall?category=misc
ASAP (hopefully this week), and then propose a patch to move it to
14 matches
Mail list logo