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 NEON asm optimizations on clang #257

Open
rvandermeulen opened this issue Oct 11, 2018 · 4 comments
Open

Enable NEON asm optimizations on clang #257

rvandermeulen opened this issue Oct 11, 2018 · 4 comments

Comments

@rvandermeulen
Copy link
Contributor

Currently, pngpriv.h has a fall-through for clang which forces the builds to use the compiler intrinsics rather than the assembly from filter_neon.S. As far as I can tell, filter_neon.S builds fine with clang 6 as long as -fno-integrated-as is used. Can we consider allowing those optimizations for at least newer versions of clang?

@ctruta
Copy link
Member

ctruta commented Apr 15, 2019

Will look into this, in the next version.

@rvandermeulen
Copy link
Contributor Author

TBH, it's such a maze of options that I'm not entirely sure we even want to do this even if it's technically possible. Especially with the more recent submissions from ARM since I opened this ticket.

@richard-townsend-arm
Copy link
Contributor

From our perspective, it's usually better to use compiler intrinsics wherever possible: it's a net gain for maintainability and Clang or GCC will usually optimise well.

@ctruta
Copy link
Member

ctruta commented Apr 16, 2019

There are two things that I prefer: fewer config options instead of more config options, and compiler intrinsics instead of hand-written assembly.

At this moment I still need to focus on defects. I want to think that I solved the most important ones, but there are still other defects left to fix. I won't spend to much on refactoring -- but I will appreciate patches.

After that, another thing that libpng needs is a configuration diet. I don't think that all of the configuration options available today are truly needed. Many of them complicate the code and create opportunities for defects, and I have in plans to let go of most of those.

Not in libpng-1.6.x, because I don't want to break compatibility. But for whatever comes next, let us call it tentatively "libpng version 2".

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

No branches or pull requests

3 participants