================
@@ -454,10 +454,22 @@ function(add_libclc_builtin_set)
set( obj_suffix ${ARG_ARCH_SUFFIX}.bc )
set( libclc_builtins_lib ${LIBCLC_OUTPUT_LIBRARY_DIR}/${obj_suffix} )
- add_custom_command( OUTPUT ${libclc_builtins_lib}
- COMMAND ${prepare_builtins_exe} -o ${libclc_builtins_lib}
${builtins_opt_lib}
- DEPENDS ${builtins_opt_lib} ${builtins_opt_lib_tgt}
${prepare_builtins_target}
- )
+ if( TARGET prepare_builtins )
+ # FIXME: Is this utility even necessary? The `-mlink-builtin-bitcode`
+ # option used to link the library in discards the modified linkage.
----------------
wenju-he wrote:
> The code object version is better done via `-Xclang
> -mcode-object-version=none` by the compiler flags. The `wchar` issue is
> confounding, that should be a property of the target so I'd imagine it
> suggests you're mixing incompatible targets.
Thanks for the suggestion. Will try it.
> Removing CPU target features like that is a _massive_ hack, but it's not an
> unprecedented one since we do similarly weird things in the ROCm Device Libs.
> Ideally we partition these libraries more intelligently, but does
> `always_inline` work?
always_inline works but it won't be used in libclc compile flags and it is
problematic to inline bitcode files with incompatible target-features. The
issue is probably that our downstream should build separate compatible bitcodes
for supported targets.
https://github.com/llvm/llvm-project/pull/174022
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
