Clang's insistence on __attribute__((target(...))) makes it impossible to build SIMD abstractions

[higher-performance]

Compiling the code

#include <immintrin.h>

template<class> struct Zero;

template<> struct Zero<__m256> {
	[[gnu::target("avx")]]
	[[gnu::always_inline]]
	inline __m256 operator()() const {
		return _mm256_setzero_ps();
	}
};

template<> struct Zero<__m256d> {
	[[gnu::target("avx2")]]
	[[gnu::always_inline]]
	inline __m256d operator()() const {
		return _mm256_setzero_pd();
	}
};

template<class T>
[[gnu::always_inline]]
static inline auto bar(T gen) {
	return gen();
}

[[gnu::target("avx")]]
void foo() {
	bar(Zero<__m256>());
}

fails with

<source>:29:2: error: AVX vector return of type '__m256' (vector of 8 'float' values) without 'avx' enabled changes the ABI
   29 |         bar(Zero<__m256>());
      |         ^
<source>:24:9: error: always_inline function 'operator()' requires target feature 'avx', but would be inlined into function 'bar' that is compiled without support for 'avx'
   24 |         return gen();
      |                ^
<source>:24:9: error: AVX vector return of type '__m256' (vector of 8 'float' values) without 'avx' enabled changes the ABI

but I don't see any reasonable annotation that could possibly be placed on bar, nor why this should be necessary at all.

Fundamentally, the target attribute is only required during codegen, for functions whose target cannot be inferred. But bar is always_inline with internal linkage, so unless its address is taken, it should not care what the target architecture is -- determining that is only the concern of the first non-inline caller, for which codegen actually occurs.

Moreover, I think the same could apply for any function whose initial declaration is also a definition. When a function's body is always available, its target attribute could always be safely inferred as the union of the targets of all its callees, and thus making its specification mandatory only introduces friction.

I feel this is a severe design limitation -- every function, even a template, is being required to know the targets of its callees, but it has no reasonable way to tell what those might be. This makes it impossible to build abstractions over SIMD code without severe code duplication.

Could the insistence on target therefore be relaxed?

[shafik]

CC @erichkeane

[erichkeane]

error: AVX vector return of type '__m256' (vector of 8 'float' values) without 'avx' enabled changes the ABI

First, this error is actually a warning, so I don't know why it is an error in your compile? You can disable it with : -Wno-psabi

As far as the restriction on inlining: it was put in place exclusively to enable the intrinsic headers IIRC, so it is perhaps not as effectively implemented as it could be. The diagnostic is important: our code generation (even out of Clang into LLVM-IR) would be broken as soon as the inliner runs, as those functions aren't propagated.

Based on your example: I could definitely see use/reason-ability of supporting multiple levels of always_inline indirection. Unfortunately the implementation of that isn't particularly easy, as we currently just do this while doing an 'emit-call' to the function with always_inline and the target attribute.

SO we would effectively have to re-implement this in the compiler, and in a way that could follow the call-graph. Typically patches that require us to generate a call-graph are considered expensive compile-time wise (as the call-graph generation requires a walk of the entire AST), so we would need to come up with a clever way to NOT make this a problem.

Effectively any TU that uses intrinsic headers (read ANY TU that is non-trivial) would run into this analysis, so we couldn't put up with any non-trivial amount of overhead here to walk the call graph.

ONE potential option: We do the analysis with depth from top-down. So any time we see a call to an always_inline function (except we SKIP this process if the current caller is always_inline?) we generate a call graph JUST for that function (which would be comparatively inexpensive), traversing (via a custom call-graph type?) ONLY through always_inline looking for the target attribute violations. But since we skip if the current caller is always_inline, we count on the callers to THAT to diagnose, and would skip the above concerns.

ADDITIONALLY: one of the problems with always_inline is that it lies. We don't diagnose when always_inline fails to inline (thanks to various types of analysis preventing it), so anything we do here is going to be necessarily an incomplete diagnostic, but we could at least do a best effort.

That said, this isn't something that I've got time to work on, but would be open to reviewing candidate patches.

[higher-performance]

error: AVX vector return of type '__m256' (vector of 8 'float' values) without 'avx' enabled changes the ABI

First, this error is actually a warning, so I don't know why it is an error in your compile? You can disable it with : -Wno-psabi

It's definitely an error that cannot be disabled (https://godbolt.org/z/6sbGnPTqe), but I have occasionally seen it generate a warning. I'm not sure exactly which occurs when.

As far as the restriction on inlining

I'm not suggesting that the restriction treat inlining differently, per se. I was wondering why one could not simply infer the target attribute of each function (as the union of those for all the callees) whenever the callee's body is available (and it isn't noinline/weak/etc.). That seems fairly straightforward to implement at first glance in a bottom-up fashion, even during parsing -- is that not the case?

(Apologies if you already explained this -- if so, I'm not sure I was able to follow.)