<div dir="ltr">On 3 February 2014 17:15, Tom Roeder <span dir="ltr"><<a href="mailto:tmroeder@google.com" target="_blank">tmroeder@google.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">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.<div>
<br></div><div>However, some object code is built with flags that are not passed at link time, and, LTO fails, e.g., with </div><div><br></div><div>LLVM ERROR: Cannot select: intrinsic %llvm.x86.aesni.aeskeygenassist<br>
</div>
<div><br></div><div>since LLVM doesn't know that that the subtarget supports this intrinsic.</div><div><br></div><div>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.</div>
<div><br></div><div>Is there a facility for encoding such information already? Or is there another way to make this work better?</div></div></blockquote><div><br></div><div>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, <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-January/069618.html">http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-January/069618.html</a> though that was targeting gcc's attribute target flag it will work for the same situation in LTO mode as well.</div>
<div><br></div></div></div></div>