================
@@ -322,22 +322,26 @@ foreach( t ${LIBCLC_TARGETS_TO_BUILD} )
if ( ARCH STREQUAL spirv OR ARCH STREQUAL spirv64 )
set( build_flags -O0 -finline-hint-functions -DCLC_SPIRV )
- set( opt_flags )
+ set( clc_opt_flags )
+ # Inline CLC functions into OpenCL builtins
+ set( opencl_opt_flags "--passes=always-inline" )
----------------
karolherbst wrote:
Yeah, we in mesa we can map all those SPIR-V CL ExtInst to either a libclc
spir-v implementation or something mesa implementation defined.
There is also like the problem with `fma`, which should never get inlined no
matter what, because some devices might actually need the emulation, so it's
either having two or mor spir-vs (with fma emulation enabled/disabled and
potential other options) or one for everything and we just pick whatever we
need.
We aren't linking against the libclc SPIR-V on a SPIR-V level, but do it way
later, so we have way more flexibility here and can cope with a single variant.
However, that relies on builtins not being inlined into other bultins
implementations.
Besides that one we are fine with optimizations as long as the SPIR-V remains
valid, which if you enable LLVM optimizations isn't simply the case anymore and
the SPIRV-LLVM-Translator ends up generating invalid SPIR-V. But this is
another issue.
https://github.com/llvm/llvm-project/pull/115699
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
