================
@@ -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.
----------------
jhuber6 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.
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?
https://github.com/llvm/llvm-project/pull/174022
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
