LTO and intrinsics

I’ve recently run across a problem with intrinsics interacting with LTO mode. The problem is that -m* compiler flags can specify architectural details (like aeskeygenassist, which depends on HasAVX and HasAES in the subtarget) but these flags are not always known at link time. This isn’t a problem with normal object code, since it simply encodes the instructions, and linking succeeds without knowing anything about these details.

However, some object code is built with flags that are not passed at link time, and, LTO fails, e.g., with

LLVM ERROR: Cannot select: intrinsic %llvm.x86.aesni.aeskeygenassist

since LLVM doesn’t know that that the subtarget supports this intrinsic.

One solution might be to encode this information in the metadata of the bitcode files and check compatibility when adding modules at link time; I’d like to have the LTO code take the union of the architecture options.

Is there a facility for encoding such information already? Or is there another way to make this work better?



There is work in progress to make it possible to enable machine
architecture specific attributes on a per-function basis. This is the
premise behind the "CGContext" thread, though
that was targeting gcc's attribute target flag it will work for the same
situation in LTO mode as well.