[LLVMdev] "target-features" and "target-cpu" attributes
Bill Wendling
isanbard at gmail.com
Sat Oct 12 02:55:47 PDT 2013
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/20131012/94006db0/attachment.html>
More information about the llvm-dev
mailing list