Closed Bug 1480594 Opened Last year Closed Last year

make the jit compilable under aarch64 windows

Categories

(Core :: JavaScript Engine: JIT, enhancement, P2)

ARM64
Windows
enhancement

Tracking

()

RESOLVED FIXED
mozilla64
Tracking Status
firefox63 --- wontfix
firefox64 --- fixed

People

(Reporter: froydnj, Assigned: froydnj)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Trying to compile any of the JIT code under aarch64 windows results in a mess of compilation errors.  It appears that Microsoft has defined macros for every aarch64 instruction, or something like that?  You get errors about "not enough arguments for function-like macro invocation mvn" or "move32".

There's also some weird warnings about undeclared identifiers like opeqneoneg.  We can sort those out later.

Note: this is not about actually providing JIT support for aarch64 windows; this is just getting the code to compile.  I suspect we'll want to turn the JIT off initially, or something like that.
Priority: -- → P2
Flags: needinfo?(ajones)
Various assembler methods don't play nicely with Windows headers and
their constant macro definitions, so we have to #undef a few things
along the way.

I'm not sure what the Right Way is to patch vixl, so posting this as a sort of
starting point.
Attachment #9005004 - Flags: review?(jitbugs)
Attachment #9005004 - Flags: review?(jitbugs) → review?(sstangl)
You could also add this to js/src/util/Windows.h maybe?

https://searchfox.org/mozilla-central/source/js/src/util/Windows.h
(In reply to Jan de Mooij [:jandem] from comment #2)
> You could also add this to js/src/util/Windows.h maybe?
> 
> https://searchfox.org/mozilla-central/source/js/src/util/Windows.h

Empirical evidence says that this is insufficient.  The macros are defined in arm64_neon.h, and if I understand the include paths correctly, we have something like:

vm/Time.h -> intrin.h -> arm64_neon.h

and vm/Time.h gets pulled in through various sources (vm/JSScript.h, vm/Realm.h, vm/DateTime.h), which I assume somehow get pulled into the macro assembler headers in some fashion?
Hm, no, intrin.h only gets pulled in on x86-ish machines.  So maybe I really do have to struggle through /showIncludes to figure out what's going on.
OK, so the intrin.h include comes via mozilla/MathAlgorithms.h -> cmath -> intrin.h, which is probably quite difficult to fix "properly". =/  I guess we could include the undefs in MathAlgorithms.h, but that feels like a hack.
Ah fair enough, thanks for checking. I thought this came in via <windows.h>
Depends on: 1488763
Comment on attachment 9005004 [details] [diff] [review]
undefine a few macros for aarch64 windows's benefit

Review of attachment 9005004 [details] [diff] [review]:
-----------------------------------------------------------------

It is an odd move on Microsoft's part to effectively reserve keywords with such short names. This patch is perfectly OK for the moment if it helps get things compiling.
Attachment #9005004 - Flags: review?(sstangl) → review+
Pushed by nfroyd@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/2ab5c5c57528
undefine a few macros for aarch64 windows's benefit; r=sstangl
https://hg.mozilla.org/mozilla-central/rev/2ab5c5c57528
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Assignee: nobody → nfroyd
Flags: needinfo?(ajones)
You need to log in before you can comment on or make changes to this bug.