[PATCH] D44387: [x86] Introduce the pconfig/encl[u|s|v] intrinsics

[Volodymyr Sapsai via Phabricator via cfe-commits]

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