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

[Dmitry Babokin]

Bill, Ben, everyone,

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.

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: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130218/166710.html

So the question - what is the state of supporting fat binaries. Is it expected to work on x86?

Thanks in advance,

Dmitry.

[Bill Wendling]

Hi Dmitry,

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).

Support for fat binaries is done on Darwin with the `lipo' command. Otherwise, I'm not sure if this really answers your question. :-)

-bw

[Dmitry Babokin]

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.

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?

Dmitry.

[Bill Wendling]

On Oct 10, 2013, at 4:22 AM, Dmitry Babokin <bab...@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


_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Dmitry Babokin]

Bill,

Are there any chances that you complete it before 3.4 is branched?

[Bill Wendling]

Hi Dmitry,

I can try my best, but it would be a bit tricky to get it all finished by then...

-bw

[Dmitry Babokin]

Looking forward to these changes! Thanks for working on it.

[Bill Wendling]

FYI:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066389.html

Please read and let me know you comments.

-bw

[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.