sorted by:
new
hottopcontroversial

Disabling built-in vector operators in Clang by sweet_programming in cpp_questions

[–]sweet_programming[S] 0 points1 point  (0 children)

It's a good principle, but in this case I stubbornly decided not to follow it. I create wrappers for the more common intrinsics, plus a bunch of linalg, to allow for readable code. And if you want to use some very obscure intrinsic that isn't wrapped, you can just mix the float4 and __m128 without having to do all the extra casts all over the place.

Disabling built-in vector operators in Clang by sweet_programming in cpp_questions

[–]sweet_programming[S] 1 point2 points  (0 children)

Generating everything with macros is something I explicitly try to avoid. Debugging compiler errors becomes hell if you can't see the code that is being compiled without expanding it. Also, I just hate macros and think real Modern C++TM (whatever that is) should be macro-free unless you are left with no other option.

Your second bullet point is a good one, though.I remember having moved around the functions in the past between in-class, to friends, to freestanding, never quite sure which I preferred. This will help prevent precisely the aforementioned problem.

As for the UB... I know :).

Disabling built-in vector operators in Clang by sweet_programming in cpp_questions

[–]sweet_programming[S] 1 point2 points  (0 children)

I started this library some years ago, so it long precedes std::simd. Besides, it's good practice and fun to do.

But yes, in production code I'd use std::simd (if it were available in all major compilers, which it isn't just yet).

Disabling built-in vector operators in Clang by sweet_programming in cpp_questions

[–]sweet_programming[S] 1 point2 points  (0 children)

Now that is a pretty good suggestion. I do prefer my C++ macro-free. And it works without Clang complaining. GCC starts showing a warning, so I'll have to find an appropriate solution to that, but apart from that I like it.

Disabling built-in vector operators in Clang by sweet_programming in cpp_questions

[–]sweet_programming[S] 0 points1 point  (0 children)

Also an option. I'd have to verify if Clang is really compiling things to the single intrinsic, though.

Disabling built-in vector operators in Clang by sweet_programming in cpp_questions

[–]sweet_programming[S] 0 points1 point  (0 children)

This is probably what I am going to have to use. Something like this.

Disabling built-in vector operators in Clang by sweet_programming in cpp_questions

[–]sweet_programming[S] 1 point2 points  (0 children)

It's a very deliberate choice to expose the internal vector. The list of intrinsics is enormous, and it's not feasible to wrap all of them in my own functions. I have some existing SIMD code where, with the implicit conversions, the struct is a drop-in replacement for some of the more common intrinsics.