Dmitry Babokin
2013-Oct-11 21:47 UTC
[LLVMdev] "target-features" and "target-cpu" attributes
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/1df4658d/attachment.html>
Bill Wendling
2013-Oct-12 09:55 UTC
[LLVMdev] "target-features" and "target-cpu" attributes
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>
Dmitry Babokin
2013-Oct-16 12:18 UTC
[LLVMdev] "target-features" and "target-cpu" attributes
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>
Possibly Parallel Threads
- [LLVMdev] "target-features" and "target-cpu" attributes
- [LLVMdev] "target-features" and "target-cpu" attributes
- [LLVMdev] "target-features" and "target-cpu" attributes
- [LLVMdev] "target-features" and "target-cpu" attributes
- [LLVMdev] "target-features" and "target-cpu" attributes