<div dir="ltr">Bill,<div><br></div><div style>Thanks for answering. To make sure that we are on the same page, let's agree on definitions :) Here, by fat binaries I mean the binary, where some functions are compiled for one flavor of x86, while others are compiled for another flavor of x86. I care about the usage model, which is important for LTO - a dispatch function (compiled for the least common denominator) + plus set of specialized functions for sse4, avx ,avx2 and etc., which are called by dispatch function depending on runtime cpu id check.</div>
<div style><br></div><div style>lipo may help achieving this on Darwin, but it's not exactly what I need. I need a solution suitable for LTO. Actually lipo may work for me as a workaround, but I need cross platform solution.</div>
<div style><br></div><div style>The current solution doesn't really address this (on x86 at least), as sub-target is not recreated if feature string doesn't match the sub-target. Instead it tries to satisfy feature string requirements using existing sub-target and this leads to the fails, that were noticed by Ben. Please correct me if my understanding is wrong.</div>
<div style><br></div><div style>So do I understand you correctly, that your new solution supposed to solve this problem?</div><div style><br></div><div style>Dmitry.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Oct 10, 2013 at 12:34 AM, Bill Wendling <span dir="ltr"><<a href="mailto:isanbard@gmail.com" target="_blank">isanbard@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><div class="h5"><div>On Oct 3, 2013, at 9:34 AM, Dmitry Babokin <<a href="mailto:babokin@gmail.com" target="_blank">babokin@gmail.com</a>> wrote:</div><br><blockquote type="cite">
<div dir="ltr">Bill, Ben, everyone,<div><br></div><div>Some time ago "target-features" and "target-cpu" attributes were introduced. As I understand, they are intended to support generation of "fat binaries" (binaries with functions generated for different CPUs), particularly to support LTO compilation, when different source files have different targets (say, one of files should support SSE2, another one SSE4). Please correct me if I'm wrong in this assumptions.</div>

<div><br></div><div>My attempts to utilize this feature fail (I generate LLVM IR directly, I'm not using clang) and this looks very similar to the one described by Benjamin in this mail thread: <a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130218/166710.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130218/166710.html</a></div>

<div><br></div><div><div>So the question - what is the state of supporting fat binaries. Is it expected to work on x86?</div></div><div><br></div></div></blockquote></div></div>Hi Dmitry,</div><div><br></div><div>I did it not so much to support fat binaries, but to support correct code generation in LTO. The problem was that it wasn't implemented correctly. Many of the objects that rely upon those features weren't updated when those features were changed. I have a new way of doing this, but it's still in the alpha stage (I haven't yet sent the whitepaper to the group).</div>
<div><br></div><div>Support for fat binaries is done on Darwin with the `lipo' command. Otherwise, I'm not sure if this really answers your question. :-)</div><span class="HOEnZb"><font color="#888888"><div><br></div>
<div>-bw</div><div><br></div><br></font></span></div></blockquote></div><br></div>