I've been working on adding AVX to LLVM and have run across a number of
questions. Here's the first one.
In some ways AVX is "just another" SSE level. Having AVX implies you
have
SSE1-SSE4.2. However AVX is very different from SSE and there are a number
of sub-features which may or may not be available on various implementations.
So right now I've done this:
def FeatureYMM : SubtargetFeature<"ymm", "X86YMM",
"true", // Cray
"Enable YMM state">;
def FeatureVEX : SubtargetFeature<"vex", "X86VEX",
"true", // Cray
"Enable VEX prefix">;
def FeatureFMA : SubtargetFeature<"fma", "X86FMA",
"true", // Cray
"Enable fused multiply-add">;
def FeatureAVX : SubtargetFeature<"avx", "X86AVX",
"true", // Cray
"Enable AVX instructions",
[FeatureSSE42, FeatureYMM,
FeatureVEX]>;
YMM, VEX and FMA are all separate features detectable through CPUID.
The key question here is whether making X86AVX a boolean feature flag separate
from X86SSELevel is reasonable.
As I've been going along I've added feature flags for SSE4a and SSE5.
These
really do need to be separate feature flags because having SSE4a and/or SSE5
does not imply that you have SSE4.2 or SSE4.1. So they can't be part of the
X86SSELevel scheme.
Opinions on whether AVX should be a separate flag or an SSELevel are welcome.
Perhaps we need to retink the whole SSELevel scheme now that AMD and Intel are
diverging. My prediction is that AMD will dump SSE5 and go with AVX
eventually, similarly to what happened with 3dNow. AVX is simply far
techincally superior.
-Dave
On Apr 30, 2009, at 3:02 PM, David Greene wrote:> I've been working on adding AVX to LLVM and have run across a number > of > questions. Here's the first one. > > In some ways AVX is "just another" SSE level. Having AVX implies > you have > SSE1-SSE4.2. However AVX is very different from SSE and there are a > number > of sub-features which may or may not be available on various > implementations. > > So right now I've done this: > > def FeatureYMM : SubtargetFeature<"ymm", "X86YMM", "true", // Cray > "Enable YMM state">; > def FeatureVEX : SubtargetFeature<"vex", "X86VEX", "true", // Cray > "Enable VEX prefix">; > def FeatureFMA : SubtargetFeature<"fma", "X86FMA", "true", // Cray > "Enable fused multiply-add">; > def FeatureAVX : SubtargetFeature<"avx", "X86AVX", "true", // Cray > "Enable AVX instructions", > [FeatureSSE42, FeatureYMM, > FeatureVEX]>; > > YMM, VEX and FMA are all separate features detectable through CPUID. > > The key question here is whether making X86AVX a boolean feature > flag separate > from X86SSELevel is reasonable.It sounds reasonable to me.> > > As I've been going along I've added feature flags for SSE4a and > SSE5. These > really do need to be separate feature flags because having SSE4a and/ > or SSE5 > does not imply that you have SSE4.2 or SSE4.1. So they can't be > part of the > X86SSELevel scheme. > > Opinions on whether AVX should be a separate flag or an SSELevel are > welcome. > Perhaps we need to retink the whole SSELevel scheme now that AMD and > Intel are > diverging. My prediction is that AMD will dump SSE5 and go with AVX > eventually, similarly to what happened with 3dNow. AVX is simply far > techincally superior.I think it's reasonable to use separate flags for the AVX features. If there's ever any code that needs to test whether the target has both AVX and a particular SSE level at the same time, the code will just have to check both conditions. Offhand, I'd say SSE4a and SSE5 ought to be separate flags too. Dan
On 30-Apr-09, at 6:38 PM, Dan Gohman wrote:> On Apr 30, 2009, at 3:02 PM, David Greene wrote: >> As I've been going along I've added feature flags for SSE4a and >> SSE5. These >> really do need to be separate feature flags because having SSE4a and/ >> or SSE5 >> does not imply that you have SSE4.2 or SSE4.1. So they can't be >> part of the >> X86SSELevel scheme. >>[...]> > Offhand, I'd say SSE4a and SSE5 ought to be separate flags too.FWIW we added a flag for SSE4A in a commit yesterday, as well as more AMD architecture types. -- Stefanus Du Toit <stefanus.dutoit at rapidmind.com> RapidMind Inc. phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463