info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Can we remove setARMHwCapFlags?
20 views
Skip to first unread message
Lars Hansen
Jul 31, 2020, 4:31:55 PM7/31/20
to dev-tech-js-engine-internals, Christian Holler
There is a whitebox testing function, setARMHwCapFlags, that is used by
exactly two test cases that I've been able to find so far, one for asm.js
and the other for wasm. (The context is bug 1656335.) It changes the ARM
hardware capabilities post-initialization, even when running on device.
That's possibly useful but it's amazingly brittle, since it means that two
checks of the HW capabilities may return different results.
Is this useful to anyone, or could we contemplate taking it out, so that
flags are stable post-startup? It's possible to set the flags using an
environment variable now, and this is a more well-behaved mechanism.
--lars
exactly two test cases that I've been able to find so far, one for asm.js
and the other for wasm. (The context is bug 1656335.) It changes the ARM
hardware capabilities post-initialization, even when running on device.
That's possibly useful but it's amazingly brittle, since it means that two
checks of the HW capabilities may return different results.
Is this useful to anyone, or could we contemplate taking it out, so that
flags are stable post-startup? It's possible to set the flags using an
environment variable now, and this is a more well-behaved mechanism.
--lars
Jan de Mooij
Aug 3, 2020, 1:56:29 AM8/3/20
to Lars Hansen, dev-tech-js-engine-internals, Christian Holler
On Fri, Jul 31, 2020 at 10:31 PM Lars Hansen <lha...@mozilla.com> wrote:
> Is this useful to anyone, or could we contemplate taking it out, so that
> flags are stable post-startup?
The tests call this with a "vfp" argument. Is that something we still care
> Is this useful to anyone, or could we contemplate taking it out, so that
> flags are stable post-startup?
about? We still have ARMv6 code we should start removing too (bug 1447577).
> It's possible to set the flags using an
> environment variable now, and this is a more well-behaved mechanism.
>
Jan
>
> --lars
> _______________________________________________
> dev-tech-js-engine-internals mailing list
> dev-tech-js-en...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
>
Lars Hansen
Aug 3, 2020, 2:46:18 AM8/3/20
to Jan de Mooij, dev-tech-js-engine-internals, Christian Holler
On Mon, Aug 3, 2020 at 7:56 AM Jan de Mooij <jdem...@mozilla.com> wrote:
> On Fri, Jul 31, 2020 at 10:31 PM Lars Hansen <lha...@mozilla.com> wrote:
>
>> Is this useful to anyone, or could we contemplate taking it out, so that
>> flags are stable post-startup?
>
>
> The tests call this with a "vfp" argument. Is that something we still care
> about? We still have ARMv6 code we should start removing too (bug 1447577).
>
The test case is changing to use "vfp,armv7" as part of a patch that's
> On Fri, Jul 31, 2020 at 10:31 PM Lars Hansen <lha...@mozilla.com> wrote:
>
>> Is this useful to anyone, or could we contemplate taking it out, so that
>> flags are stable post-startup?
>
>
> The tests call this with a "vfp" argument. Is that something we still care
> about? We still have ARMv6 code we should start removing too (bug 1447577).
>
about to land, since it's in the wasm subdirectory and wasm requires
armv7. Thinking about it, I could improve that patch to gate explicitly on
armv7. I'm not sure where Ion in general gates on armv7, if it does
(haven't looked yet).
>
>
>> It's possible to set the flags using an
>> environment variable now, and this is a more well-behaved mechanism.
>>
>
> Fuzzing (and jit-test annotations) would probably prefer a shell flag..
>
I think. I can look into making that change.
--lars
0 new messages