[Clang] Target multiversioning does not allow inlining

[jhuber6]

Clang is supposed to support target multi-versioning where applying the target attribute multiple times will result in several functions that are overloaded on the callers target type. This unfortunately generates functions that contain the set of all targets enabled for that function, which results in only the most permissive use to be inlined. I am trying to use this to create generic SIMD heplers https://godbolt.org/z/7f3aPfeeW.

The calling AVX2 target will have these attributes set.

attributes #2 = { mustprogress nounwind uwtable "min-legal-vector-width"="256" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+avx,+avx2,+cmov,+crc32,+cx8,+fxsr,+mmx,+popcnt,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+x87,+xsave" "tune-cpu"="generic" }

While the callee will have these attributes. Because it contains avx512f it's considered incompatible and cannot be inlined.

attributes #3 = { mustprogress nounwind uwtable "min-legal-vector-width"="256" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+avx,+avx2,+avx512f,+cmov,+crc32,+cx8,+evex512,+f16c,+fma,+fxsr,+mmx,+popcnt,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+x87,+xsave" "tune-cpu"="generic" }

Is this intentional behavior? If I manually eliminate the offending attributes the code words as expected and gives me optimal code no matter which target is calling. It seems bizarre that we would multi-version the functions but still create them with incorrect attributes for the target.

[jhuber6]

@erichkeane Do you know how this is supposed to behave?

[jhuber6]

I suppose this is because we don't just support templated multi-versioning so we create templated calls but copies of the same function. Definitely seems like I've somehow made something that kind of works when it's not intended to work. I'm wondering what's required to actually make this function. It'd need to only take the ABI of the calling function somehow.

Mostly I'd just like some way to do this without explicitly multi-versioning the template, I don't know if that's possible right now.

[efriedma-quic]

Inlining is intentionally disabled for this kind of mismatch because in general, inlining could cause an error in the backend, or crash at runtime, if you try to use a feature that isn't enabled. (The inliner doesn't try to check if the function actually uses a problematic feature; it just trusts the attributes.)

I think you can write a template like that by wrapping your vector type in a class. That way, the algorithm itself doesn't need any target attributes, and it can be inlined. And then the wrapper methods can be inlined because the attributes match.

[jhuber6]

Inlining is intentionally disabled for this kind of mismatch because in general, inlining could cause an error in the backend, or crash at runtime, if you try to use a feature that isn't enabled. (The inliner doesn't try to check if the function actually uses a problematic feature; it just trusts the attributes.)

In an ideal world we would just generate a variant of this function that only has the caller's target attributes on it. If you look at the AST we generate different functions but they all have the full set of features. The fact this this looks like it kind of works is incidental.

I guess it would need to work kind of like propagating any other template argument, except it's the feature set. It's unfortunate because the generated code is very close to working here, because we generate different template functions for avx, sse, etc, they just don't have the right attributes.

I think you can write a template like that by wrapping your vector type in a class. That way, the algorithm itself doesn't need any target attributes, and it can be inlined. And then the wrapper methods can be inlined because the attributes match.

I don't think this works, and it would also defeat the point because we'd no longer be able to use the LLVM vector as a primitive type which is what I'm going for.

Do you happen to know how difficult it would be to permit this to work in a reasonable manner? Right now we reject templated multi-versioned functions (I don't even know why this one compiled), but it seems like it would work as desired if we look the caller's ABI into account when we cloned the function template. I'm not overly familiar with clang AST handling so I'm not sure what's required there.

[efriedma-quic]

Something like the following has obvious semantics, and probably isn't too hard to implement; just needs a few changes to template instantiation.

template<const char* FEAT, typename T> [[gnu::target(FEAT)]] T f(T v) { return v+v; }

I'm not sure what "taking the caller's ABI into account" looks like if you're not passing it in explicitly. A C++ template has to be instantiated purely based on the template arguments. I guess, independent of templates, we could invent some variation of target_clones that doesn't do runtime feature detection, but that doesn't seem widely useful.

[jhuber6]

Something like the following has obvious semantics, and probably isn't too hard to implement; just needs a few changes to template instantiation.

template<const char* FEAT, typename T> [[gnu::target(FEAT)]] T f(T v) { return v+v; }

Yeah, that's exactly what I'm looking for. Though, practically, I was hoping to use this for the LLVM libc as we start to add support for things like libmvec and fast string functions. We'd need to decide if it's acceptable to require a really new compiler.

I've never looked into template instantiation, seems this would need to relax the requirement for attributes being a string literal?

I'm not sure what "taking the caller's ABI into account" looks like if you're not passing it in explicitly. A C++ template has to be instantiated purely based on the template arguments. I guess, independent of templates, we could invent some variation of target_clones that doesn't do runtime feature detection, but that doesn't seem widely useful.

I meant it in the same way that you showed above.

[[gnu::target("avx512f")]] caller() {
  callee<avx512f>();
}

The runtime feature detection does kind of throw me for a loop. Do you happen to know at which level we emit the ifunc based dispatch? Likely we'd want a stack of these functions and only emit ifunc at the bottom. Basically since this has libc in mind we'd need strlen to dispatch to the different variants as a generic symbol. Is there a way to put target attributes on the function without implying runtime dispatch?

[efriedma-quic]

I've never looked into template instantiation, seems this would need to relax the requirement for attributes being a string literal?

All the relevant checks are specific to the attribute in question. But basically, yes. But there are some minor complications that we'd need to introduce the notion of "dependent feature context" to delay checks on the dependent function, and then perform the appropriate checks during instantiation.

Is there a way to put target attributes on the function without implying runtime dispatch?

If you specify a single target, we assume the user did the appropriate checks. Multiversioning implies runtime dispatch.

[jhuber6]

I've never looked into template instantiation, seems this would need to relax the requirement for attributes being a string literal?

All the relevant checks are specific to the attribute in question. But basically, yes. But there are some minor complications that we'd need to introduce the notion of "dependent feature context" to delay checks on the dependent function, and then perform the appropriate checks during instantiation.

Is there a way to put target attributes on the function without implying runtime dispatch?

If you specify a single target, we assume the user did the appropriate checks. Multiversioning implies runtime dispatch.

Cool, so in this 'templated' case it would be as if the user provided a single target for the function. Most of this is just my desire to have optimal vector variants without needing to do the standard solution of a massive wrapper class with a different function for every ABI.

[jhuber6]

It's really unfortunate that it reject templates even when used as a single function https://godbolt.org/z/efcq97Kjn. I was hoping I could just do the dispatch manually through some macro magic, but even though we're not doing any multi-versioning here (just using it to get the appropriate CPU attrs) it rejects it.

Scratch that, using default at all triggers multi-versioning. I suppose 'default' this context is just leaving the attribute off.