Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable compiler on NetBSD, DragonFly, illumos and Solaris #2343

Merged
merged 2 commits into from
Nov 15, 2024

Conversation

ncruces
Copy link
Collaborator

@ncruces ncruces commented Nov 15, 2024

This culminates this series of changes, enabling the compiler on:

  • NetBSD amd64 and arm64
  • DragonFly BSD amd64
  • illumos amd64
  • Solaris amd64

We're not currently testing arm64 for either FreeBSD or NetBSD, but I've tested them. The emulation is slow, I'm not sure if it's worth it. The others are not supported Go arm64 targets.

OpenBSD was not added because it failed with an SIGSEGV. If anyone wants to take a stab at this, I'd welcome it.

Signed-off-by: Nuno Cruces <ncruces@users.noreply.github.com>
Signed-off-by: Nuno Cruces <ncruces@users.noreply.github.com>
@mathetake mathetake merged commit 0a20795 into tetratelabs:main Nov 15, 2024
50 checks passed
@ncruces ncruces deleted the compiler branch November 15, 2024 15:19
@ncruces
Copy link
Collaborator Author

ncruces commented Nov 21, 2024

Just adding a note that #2345 essentially disables the compiler on arm64 NetBSD.

It can be force enabled with wazero.NewRuntimeConfigCompiler() (which disables CPU detection), but you run the risk of crashes at runtime (if your CPU doesn't support the necessary instructions).

@anuraaga
Copy link
Contributor

anuraaga commented Nov 21, 2024

@ncruces Just to understand why does #2345 (excellent pr number by the way) disable it? I figured it would use compiler as long as it's arm 8.1 even on NetBSD. Or does the OS actually expose feature flags differently?

Edit: oops got it, didn't realize they would be hidden from apps on certain OSes, that's interesting.

@ncruces
Copy link
Collaborator Author

ncruces commented Nov 21, 2024

This should offer a good explanation:
https://kernel.org/doc/Documentation/arm64/cpu-feature-registers.txt

Unlike the Intel CPUID instruction, these ARM registers are not made available to user space.

Linux and FreeBSD do make them available, somehow (which I don't fully understand), but on other OSes just running that code crashes the process.

Any other OS where this works, I'm OK with whitelisting, but these are the only two in the Go codebase. So I only run feature detection for those two OSes.

On macOS we can assume the chip supports it (on desktop macOS the M1 is ARMv8.4, and iOS doesn't even support a JIT).

On Windows, Windows 11 requires these, Windows 10 doesn't. Given the big recent push, I argue that Windows 11 covers most of the target systems.

@ncruces
Copy link
Collaborator Author

ncruces commented Nov 21, 2024

This also means that post #2345 is not a regression vs v1.8.1: the only systems where we disable the compiler by default, are the ones were sure are missing instructions (amd64 without SSE4.1 or arm64 without atomics), and you can still force enable the compiler anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants