Consider marking functions constexpr

[nemequ]

Someone was asking about something like this on StackOverflow recently. I'm skeptical that it's worth the effort, but I thought I'd at least open up the issue for discussion.

The basic idea is that with C++2a (or C++11 with something supported by HEDLEY_IS_CONSTEXPR_, or maybe c2x if they decide to add constexpr to the language) it should be possible to have pretty much everything in SIMDe be constexpr by using the portable implementation at compile-time.

Unfortunately, the implementation could get pretty messy. We would need to do something like

#if defined(HAVE_NATIVE_VERSION)
#  if defined(SUPPORTS_CONSTEXPR)
if (!std::is_constant_evaluated())
#  endif
return native_version();
#endif

#if defined(SUPPORTS_CONSTEXPR) || !defined(HAVE_NATIVE_VERSION)
return portable_version();
#endif

In every function. Also, HAVE_NATIVE_VERSION should also include using other ISA extensions (e.g., NEON for an x86 function)… really any time where we have a faster alternative to the portable version.

Obviously this complicates the implementations somewhat, but not prohibitively so. It would take a fair amount of time to go back and add to all the existing functions, but it's pretty straightforward work (good first issue, maybe?).

My main concern is just that I'm not sure it's worth the effort; SIMD instructions tend to be used mostly when there is a lot of data that can't be computed at compile-time, so this feels like a solution in search of a problem. That said, if people really find themselves in situations where this would be useful on a somewhat regular basis, I could be convinced to (accept a patch to) add it to SIMDe.

If anyone cares about this one way or the other please comment. If people don't respond I'll assume nobody cares and it won't happen. If you don't want to comment but do want to vote, thumbs up/down for yes/no.

[GabeRundlett]

In my original post on SO, I intend to use SIMD in an overloaded operator function to add two mathematical vectors together. Although this makes the addition fast at runtime, since I'm using SIMD in these functions, I cannot use the operators with constexpr variables. This forces simply evaluabe vectors that are comprised of some combination of expressions using these overloaded operators to be evaluated at runtime, which is not optimal.

[nemequ]

I understand what constexpr does, and what you're trying to do. What I'm trying to figure out is whether there is really a practical application, or do you just think it would be a cool feature (which I agree with, but I don't think is enough of a reason to justify the amount of effort involved).

People don't generally have a lot of data available at compile-time, and if you do you should probably be pre-processing it instead of relying on the compiler and constexpr. So the only time I can really see this coming in handy is if you have a very hot loop that changes depending on a compile-time parameter in a non-trivial way, which isn't something I see in the wild very often at all.

[nemequ]

I just realized that may have sounded a bit snarky, which isn't what I intended. I think this is an interesting idea, I'm just having trouble thinking of a reason you would want to do what you described that wouldn't be better addressed by a different solution.

If there is something I'm missing I'd definitely consider implementing this, I just don't want to do something that would add a lot of complexity to SIMDe without a good reason.

[nemequ]

I'm going to close this, but I'm still open to the idea if anyone can convince me that it's worth the additional complication.

In the meantime, maybe Iris might be more open to this? The depend pretty heavily on templates so you wouldn't need to modify nearly as many places as for SIMD. Unfortunately they don't have the code that SIMDe does for accelerating one ISA extension with another, or AFAIK even a native implementation (though I could be wrong about that part).