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? Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: <lists.llvm.org/pipermail/llvm-dev/attachments/20140203/5d732dbc/attachment.html>
On 3 February 2014 17:15, Tom Roeder <tmroeder at google.com> wrote:> 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, lists.cs.uiuc.edu/pipermail/llvmdev/2014-January/069618.html though that was targeting gcc's attribute target flag it will work for the same situation in LTO mode as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: <lists.llvm.org/pipermail/llvm-dev/attachments/20140203/9dfb79e0/attachment.html>