clang's output looks much better than GCC's here: https://godbolt.org/z/es3pz5. Like I said in the issue, I think that will only happen for the simpler functions, though :(
@nemequ Remark: I think LE/GE would be more in line with standard abbreviations than LTE/GTE but I don't really care. Could you let me know when you have done this, please? Or do you want me to do it? Then I'll create a new branch (pr/445 as you suggested) based on the new master, integrate cgt and push it to my fork where you can see and review it. When we agree on this I'll modify the others in the same vein. Would this be OK? I also have corrections to get_low and my C++/C include modifications to skel. Should I generate a separate PR for these? Maybe I need to do cgtz as well as there is nothing to simplify in cgt.
Sorry, I have my head buried in something else right now. Anyways, I'll push the change in a bit, should be in master within an hour or so.
I think it would be a good idea to translate these into semi-global macros e.g.
SIMDE_NEON_CONVERT_64_TO_128 which can be easily globally enabled or disabled. This would be useful in the case of my clang bug or if we find that they are worse than auto_vectorization on some platforms. I could put this in types.h. What do you think?
@rosbif, I commented in the PR (sorry, I thought I did that earlier today). I don't think you need to be that precise; just
SIMDE_NEON_ENABLE_VECTOR_EXPANSION to cover everything that should be fine. As I wrote in the PR, I'm not comfortable with the idea of mixing sizes… I think that's asking for trouble.
I found a weird error compile error on GCC 5.4 (ubuntu 16.04 default):
$ cat test.cpp
#define SIMDE_ENABLE_NATIVE_ALIASES
#include "x86/sse2.h"
#include "smmintrin.h"
int main(int argc, const char** argv) { return 0; }This fails with any optimization flag g++ test.cpp -O3 -msse2 and compiles without. This is somehow happening in MMseqs2 since we include SIMDe and then some stdc++ file includes x86intrin.h.
I have a workaround by moving the include that includes SIMDe further down so it gets included after libstdc++ does it's thing.
@nemequ I have pushed a new version of #445 to the pr/445 branch of my fork for you to comment on. Tests are in progress (with a few stupid errors).
@rosbif ok, I'll take a look in a bit; I added a bunch of implementations to the neon headers last night, working on cleaning them up and committing them now…
@milot-mirdita the functions should be safe since the native aliases use macros, but I'd they clobber our macros we can't control what gets executed...
But I'll play with it, maybe I can find a workaround
@nemequ For #445 Travis CI is clean now in pr/445, even WASM which is unfamiliar and was completely untested :-)
What does "2 annotations" signify in the failure e-mail?
BTW, is it just me or has Travis been really slow lately?
Looks like you figured it out, all builds are passing \o/
Travis CI doesn't seem slow to me.
@rosbif, I'll take a look in ~ 1 hour, there are just a couple little things I need to take care of first.
Yes I imagine you're very busy.
BTW, now that you've had a chance to use the new SIMDE_NATURAL_VECTOR_SIZE stuff, are you good with it?
Maybe SSE (or even SSE2 because SSE isn't much use to me as I'm not a floating point person) is considered a minimum for SIMDe.
TBH I'm rather mystified by this; you would think that the compiler would be able to track which registers are used for FP and which are used for MMX… I think modern compilers can do this, but I know MSVC will issue warnings if you mix FP and MMX, and since I'm not really familiar with all the details I'm really nervous about using MMX for anything on x86.
That's why I think implementing MMX using SSE would be awesome, though.