Open rvandermeulen opened 6 years ago
Will look into this, in the next version.
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.
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.
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".
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?