Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

extra header to map the simde names to the original names #38

Closed
hexdump0815 opened this issue Mar 31, 2019 · 2 comments
Closed

extra header to map the simde names to the original names #38

hexdump0815 opened this issue Mar 31, 2019 · 2 comments
Labels

Comments

@hexdump0815
Copy link

hi nemequ,

just one other idea i ran across while using simde: it would be really nice if there would be some optional extra header available as part of simde, which maps all the simde_ names back to their regular counterparts. this way one could simply replace the occurence of the original *mintrin.h includes with the simde headers plus those new headers and should be able to run code unmodified if everything works fine. right now it looks like i have to change all occurences of the original sse _m..., _m... etc to their simde counterparts by hand or some script which is error prone.

maybe such a suggested new header might be created automatically somehow from the simde sources

best wishes - hexdump

@nemequ
Copy link
Member

nemequ commented Mar 31, 2019

This seems like a really good idea at first. In fact, IIRC earlier versions of SIMDe did actually support this, though not with an additional header; I believe you had to define something like SIMDE_EMULATE_NATIVE before including the SIMDe headers. Unfortunately it has some nasty implications.

The biggest problem is that SIMDe isn't designed just for porting to other architectures (e.g., running SSE code on ARM), but for porting to anything which doesn't have native support for the ISA extension in question (e.g., AVX2 on processors that don't support it). If we did this, we would quickly run into problems with incompatible types, such as __m128i using the native version (since the CPU supports SSE2) but the SIMDe implementation expects a simde__m128i.

It also introduces various other less severe issues, like creating identifiers that start with _ (which is disallowed by the C standard, probably C++ too).

FWIW, I really haven't had any trouble automatically converting stuff to SIMDe, and I don't even bother with a script; just something like

find -iname '*.c' -o -iname '*.h' -exec sed -i -e 's/__m/simde__m/g' {} +
find -iname '*.c' -o -iname '*.h' -exec sed -i -e 's/_mm_/simde__mm_/g' {} +

You may have to add some extensions (*.cc, *.cpp, *.hpp, etc.) for C++ projects, but it's pretty straightforward. I imagine if someone uses some of the Microsoft extensions (_x_mm_*) that might be a problem… it wouldn't be hard to account for that in a script, and I'd be willing to add such a script if anyone needs it (in Bash; PowerShell or Batch would have to wait for someone else).

@nemequ nemequ closed this as completed Mar 31, 2019
@hexdump0815
Copy link
Author

i see your point. i can just say from my experience with this one project, that a simple find and replace does not work too well for larger projects, as the replace would hit a lot of non-sse code as well. this is what i had to come up with to get things converted for the vcvrack 1.0 branch and the Valley plugin for it:

$ cat simde-ify.sh 
#!/bin/bash

sed -i 's,<mmintrin\.h,<x86/sse2.h,g;s,xmmintrin\.h,x86/sse2.h,g;s,pmmintrin\.h,x86/sse2.h,g;s,emmintrin\.h,x86/sse2.h,g;s,^_m,simde_m,g;s,^__m,simde__m,g;s,\ _m, simde_m,g;s,\ __m, simde__m,g;s,\t_m,\tsimde_m,g;s,\t__m,\tsimde__m,g;s,(_m,(simde_m,g;s,(__m,(simde__m,g;s,\,_m,\,simde_m,g;s,\,__m,\,simde__m,g;s,~_m,~simde_m,g;s,~__m,~simde__m,g;s,:_m,:simde_m,g;s,:__m,:simde__m,g;s,\._m,.simde_m,g;s,\.__m,.simde__m,g;s,simde_mode,_mode,g;s,simde_msgCount,_msgCount,g' $1

and that then run recursively across the project :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants