-
Notifications
You must be signed in to change notification settings - Fork 67
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
wavpack 5.3.0 fails to compile on Apple Silicon #93
Comments
Thanks for reporting this! I currently have no plans to implement ARM64 assembly (which would require a rewrite of the existing ARM assembly) so for now I'll try to disable the ARM code for ARM64. Unfortunately I have no way to try this on Apple, so could you please verify that this works and close the issue if it does? Cheers! |
The target triplet is sometimes called |
Yes, it might be, and I would certainly have to add that if I implemented 64-bit ARM code. But for now the purpose is to just not trigger the At first I tried to create a pattern that matched |
Well, the plot thickens! I just got a report that an Apple Silicon build failed because the host was reported as @fxcoudert You obviously had a failure and posted that your host was In any event, if the host CPU on Apple Silicon can sometimes be simply Being too picky on asm choices is better than being too loose because in the worst case we still build, and these days processors are so much faster than when I created that asm code that it probably makes no practical difference. |
@dbry I stated what the usual/canonical triplet was for the architecture, i.e., what an up-to-date We have fixed the issue in Homebrew by explicitly passing |
Ah, that explains some mysteries! I wish I’d known I was going down the wrong path before my release, but unfortunately the whole The latest Anyway, I put |
Just update the config.guess and config.sub files manually at https://www.gnu.org/software/gettext/manual/html_node/config_002eguess.html says, it's good. |
If anyone kept the old MMX intrinsic code for x86 (or any intrinsic code), there might be a way to use them on a couple other architectures with https://github.com/simd-everywhere/simde. The mmx.h implementation has redirections to Neon and Loongson MMI (in some ways a carbon copy of MMX on MIPS). [oh no i am now curious about whether the C compiler will unroll and make its own simd] The answer is no. I grabbed the I guess that would be why the assembly functions don't use the In other news, asm isn't doing much in my very unscientific test -- bash times
Ryzen 5 3600, auto-boosted to 3.99 GHz. MSYS2 (not the most performant environment), gcc 11.3.0, default generic flags besides -fopenmp-simd. |
let the universal build to work for now, see dbry/WavPack#93
If this is still an issue can something like this be added to your CMake configuration? |
Thanks for this post and your investigation...sorry I didn't respond earlier but I kept forgetting it was here! The funny thing is that I recently switched from an Intel-based laptop to a Ryzen machine (HP Dev One) and the advantage of the MMX code seems to have completely disappeared, and this is exactly what you are seeing! It usd to provide a decent bump, but I don't have the expertise (or motivation) to figure out what's going on. Perhaps moving the asm to something newer than MMX might help, but like you point out, the only thing that can be SIMD'd is the stereo pairs. Such is the nature of codecs that adapt every sample. Of course, what does make a huge improvement is the multi-threading I added recently, and that's the direction I'm more inclined to pursue in the future. Thanks again, and sorry for being so unresponsive! 😄 |
I don't know. Is this still a problem? I was under the impression that with the latest changes and new |
We are not updating often submodules and IDK if CMake is working together with Autoconf in your project, we had issues with our checkout and solved that way our side, so I saw this issue still open and asked :) |
Ah, well the issue is still open because I'm lazy about closing them and hope the OP will do so. Thanks for posting and unless I here otherwise in the near future that this is still an issue, I'll close it myself. Cheers! |
wavpack 5.3.0 fails to compile on Apple Silicon (aarch64-apple-darwin20) because the ARM assembly is not recognised by the system compiler (Apple's clang 12):
The text was updated successfully, but these errors were encountered: