75ac790357
Darktable source code is heavily tuned for GCC and its optimizations. It always required some work to make it compile with LLVM. With LLVM 14+, new errors around `static inline __attribute__((target-clones))` appeared: the compiler failed to link the final executable because there was multiple copies of the same ifunc resolver (the code originated from a header included in a couple places). Apparently GCC knows how to deal with the "static-inline"-ness of the resolver somehow. Unfortunately, even with GCC, we get several compilation failures because the source files enable Graphite optimizations (using `#pragma`) but our GCC compiler has Graphite disabled by default. All the patches included in this commit simply delete all the corresponding `#pragma`. I suppose Darktable will be slightly slower because of this, but I didn't measure anything. In the end, the dependencies of the port change a bit because GCC replaces LLVM.
23 lines
840 B
C
23 lines
840 B
C
--- src/common/extra_optimizations.h.orig 2022-12-14 15:18:18 UTC
|
|
+++ src/common/extra_optimizations.h
|
|
@@ -17,19 +17,3 @@
|
|
*/
|
|
|
|
#pragma once
|
|
-
|
|
-/* Enable extra optimizations on GCC by including this header at the very
|
|
- * beginning of your *.c file (before any other includes). This applies
|
|
- * these optimizations for all of the source file.
|
|
- *
|
|
- * we use finite-math-only because divisions by zero are manually avoided
|
|
- * in the code, the rest is loop reorganization and vectorization optimization
|
|
- **/
|
|
-
|
|
-#if defined(__GNUC__)
|
|
-#pragma GCC optimize ("unroll-loops", "split-loops", \
|
|
- "loop-nest-optimize", "tree-loop-im", \
|
|
- "tree-loop-ivcanon", "ira-loop-pressure", \
|
|
- "variable-expansion-in-unroller", \
|
|
- "ivopts", "finite-math-only")
|
|
-#endif
|