[LLVMdev] LTO and intrinsics

[Nick Lewycky]

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,
http://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: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140203/9dfb79e0/attachment.html>