[LLVMdev] "target-features" and "target-cpu" attributes

[Dmitry Babokin]

Bill,

The solution that you are proposing does look good to me. It matches
general scheme that I had in mind thinking about this problem. Looking
forward to see it implemented.

Dmitry.


On Sat, Oct 12, 2013 at 1:55 PM, Bill Wendling <isanbard at gmail.com> wrote:

> FYI:
>
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066389.html
>
> Please read and let me know you comments.
>
> -bw
>
> On Oct 11, 2013, at 2:47 PM, Dmitry Babokin <babokin at gmail.com> wrote:
>
> Looking forward to these changes! Thanks for working on it.
>
>
> On Fri, Oct 11, 2013 at 10:32 PM, Bill Wendling <isanbard at gmail.com>wrote:
>
>> Hi Dmitry,
>>
>> I can try my best, but it would be a bit tricky to get it all finished by
>> then...
>>
>> -bw
>>
>> On Oct 11, 2013, at 4:10 AM, Dmitry Babokin <babokin at gmail.com> wrote:
>>
>> Bill,
>>
>> Are there any chances that you complete it before 3.4 is branched?
>>
>>
>> On Thu, Oct 10, 2013 at 10:16 PM, Bill Wendling <isanbard at gmail.com>wrote:
>>
>>> On Oct 10, 2013, at 4:22 AM, Dmitry Babokin <babokin at gmail.com> wrote:
>>>
>>> > Bill,
>>> >
>>> > 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.
>>> >
>>> Okay. The terminology was a bit overloaded. :-)
>>>
>>> > 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.
>>> >
>>> > 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.
>>> >
>>> > So do I understand you correctly, that your new solution supposed to
>>> solve this problem?
>>> >
>>> That's correct. It still needs to be implemented (of course), but that's
>>> the eventual goal.
>>>
>>> -bw
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131016/fac45dd7/attachment.html>