1223229 - Add js 32-bit ARM-simulator Windows shells to treeherder

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

+++ This bug was initially created as a clone of Bug #1155473 +++

Since we have 32-bit ARM-simulator Linux shells, and are adding Mac ones in bug 1155473, we might want to consider adding Windows ones while we're at it.

Should we?

Comment 1

[Steve Fink [:sfink] [:s:]]

I don't know, I'm not the one who would use these builds, really. But my guess is that there's no reason to have Windows ARM builds. The builds are for testing the jit code generated for an ARM architecture device, in an environment more amenable to automation and debugging than an actual ARM device. If there were errors specific to a Windows ARM build, we wouldn't really care, since that's not a shipping configuration. "When running under Windows, we generate incorrect ARM code for some strange reason." So what? We'll never do that until we decide to port to a Windows phone or something.

But jandem would certainly have a more informed opinion than I would. (It's also likely that the ARM simulator simply does not run on Windows.)

Comment 2

[Jan de Mooij [:jandem]]

Having Windows ARM simulator builds does have some benefits: MSVC compiling the ARM backend might expose some general correctness issues. Just like the undefined behavior bug we found last week on OS X with Clang running the ARM simulator. ARM simulator fuzzing on Windows should also help there though (assuming it builds and works).

I doubt that's enough reason to add those builds. What's nice about the OS X and Linux builds is that devs actually use the ARM simulator on these platforms, so Treeherder ensures we don't break this configuration.

Also, having 2 different compilers (GCC and Clang) is nice to avoid relying on GCC-extensions/bugs in the ARM backend, adding a third one seems less important.

Comment 3

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to Jan de Mooij [:jandem] from comment #2)
> I doubt that's enough reason to add those builds.

Having it in treeherder ensures that we don't at least fail to compile on this configuration. I have had instances of wasted time and effort from Mac ARM-simulator builds failing to compile in the past, that I don't want to go through again.

If we don't put it up, we don't fuzz it, to save on frustration. We don't test it. Simple line drawn in the sand. (which means bugs similar to that undefined behaviour bug won't be found)

As a compromise, how about just having these Windows builds at least compile for treeherder, but only run a small subset of (jit-)tests if any?

Comment 4

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

I spoke to :jandem in-person, and the conclusion is that the value proposition of this, isn't immediately apparent since we already have ARM-simulators for Linux and Mac (and we don't have Windows ARM phones yet), so resolving INCOMPLETE for now. We can revisit this in the future if needed.