vsapsai added a comment. Having in bitcode something like `@llvm.x86.encls.64` is better than inline assembly because we understand the meaning of the bitcode while we don't parse assembly and have a very limited understanding of what it is doing.
The use case we need to support is basically --- a/clang/test/Modules/compiler_builtins_x86.c +++ b/clang/test/Modules/compiler_builtins_x86.c @@ -1,6 +1,7 @@ // RUN: rm -rf %t // RUN: %clang_cc1 -triple i686-unknown-unknown -fsyntax-only -fmodules -fimplicit-module-maps -fmodules-cache-path=%t %s -verify -ffreestanding // RUN: %clang_cc1 -triple i686-unknown-unknown -fsyntax-only -fmodules -fmodule-map-file=%resource_dir/module.modulemap -fmodules-cache-path=%t %s -verify -ffreestanding +// RUN: %clang_cc1 -triple i686-unknown-unknown -fsyntax-only -fmodules -fimplicit-module-maps -fmodules-cache-path=%t %s -verify -ffreestanding -fno-gnu-inline-asm // expected-no-diagnostics #include<x86intrin.h> And this case isn't affected by cpuid, so we don't plan to change that as well as Windows-specific assembly in immintrin.h. While writing the response, it occurred to me that another solution might be changing `-fno-gnu-inline-asm` to cover only actually called code. If you don't call `_pconfig_u32`, it shouldn't matter that in the header it is implemented with inline assembly. But this is an early idea, I need to discuss with the team if it will work and if there are other constraints I'm missing. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D44387/new/ https://reviews.llvm.org/D44387 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
