search for: intrin

Hi, Here are 3 suggested patches. 1. Build test for cmake and run the test in gitlab-ci. 2. Disable the message box on Windows on abort that cause test hangs in CI. 3. Build time improvement by removing unnecessary includes of stdio.h in production code and change to a lighter header intrin.h -> intrin0.h (windows only). Attached screenshot of measurement but it resulted in 14% buildspeed compared to master on Windows 64 debug builds on my setup. As most improvements comes from change intrin.h the impact on other platforms will not be that much. //Marcus -------------- next part -...

...r placed in a header. I'll fix that. > 3. denoise.c doesn't seem to be in tar.gz, it is in the visual studio > project file though. The project file isn't up-to-date (I've never even compiled Speex in Win32). The file's been renamed to preprocess.h > We ran the SSE intrinics code through some test on windows over here and > all I can say is - it sucks. A room filled with Monkeys could generate > better SSE code. Having stated that let me describe why. You mean a room filled with monkeys could generate a better compiler? :) > We use Visual Studio 6, SP5...

...earch_sse.h line 34. 2. Compile Error with quant_lsp.c line 55. M_PI is undefined. Either it needs to be included in that file or placed in a header. 3. denoise.c doesn't seem to be in tar.gz, it is in the visual studio project file though. Now onto the actual SSE tests. We ran the SSE intrinics code through some test on windows over here and all I can say is - it sucks. A room filled with Monkeys could generate better SSE code. Having stated that let me describe why. We use Visual Studio 6, SP5 with the processor pack as the main development platform. For some unknown reason, it de...

> Good catch on the debug mode. After compiling the same code in > release mode it does appear to be using all the registers correctly. Give > us a few days to integrate our run-time flags into 1.1.4 and I will let you > know how are testing turns out. Just a note. With the last optimization I did in cb_search.c, it's no longer easy to have a run-time SSE flag. The

...x that. > > > 3. denoise.c doesn't seem to be in tar.gz, it is in the visual studio > > project file though. > >The project file isn't up-to-date (I've never even compiled Speex in >Win32). The file's been renamed to preprocess.h > > > We ran the SSE intrinics code through some test on windows over here and > > all I can say is - it sucks. A room filled with Monkeys could generate > > better SSE code. Having stated that let me describe why. > >You mean a room filled with monkeys could generate a better compiler? :) > > > We...

...t's something I do locally and we do > have a bot setup for it, but it uses ninja: > http://lab.llvm.org:8011/builders/clang-x86-win2008-selfhost/ > Obviously everyone's setup is slightly different and getting diversity in > testing is good. > > These undefined symbols are intrinsics that should be taken care of by > clang/lib/Headers/Intrin.h, but somehow that isn't being chosen in > llvm/lib/Support/Host.cpp. I have a feeling that this line is getting > MSVC's builtin header instead of clang's: > #ifdef _MSC_VER > #include <intrin.h> >...

Jean-Marc, Are you sure that you don't need to add just -msse to enable the intrinsics rather than a full fledged -march=pentium3? I did some playing around and I can get intrinsics code to compile with -march=i686 -msse on linux with that. Check out: http://groups.google.com/groups?q=enable+gcc+sse+intrinsics&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=ugn...

Sorry about that, let me check the correct version for the intrin0.h include guard. //Marcus ________________________________ From: Ralph Giles <giles at thaumas.net> Sent: Thursday, June 11, 2020 19:31 To: Marcus Asteborg <xnorpx at outlook.com>; opus at xiph.org <opus at xiph.org> Subject: Re: [opus] Misc patches Speaking of needing more com...

...esn't actually work. I'll fix that. > 2. xapian-core when built with GCC: > > checking whether __builtin_add_overflow is declared... yes > ... > checking whether _addcarry_u64 is declared... no > > There is actually _addcarry_u64 in GCC too, but it's in x86intrin.h > instead of intrin.h. This is no problem either, since it's superimposed > by __builtin_add_overflow anyway. I think __builtin_add_overflow() is going to be as good an option (and possibly a better option where both are supported) so this doesn't seem a problem unless there's...

OK, fixed the problem with the intrin.h header that doesn't exist in previous versions of VS... -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: JIT.patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060126/7e55b0d0/attachment.ksh>

...1. Build test for cmake and run the test in gitlab-ci. OK, merged. > 2. Disable the message box on Windows on abort that cause test hangs in CI. Merged too. > 3. Build time improvement by removing unnecessary includes of stdio.h > in production code and change to a lighter header intrin.h -> > intrin0.h (windows only). Attached screenshot of measurement but it > resulted in 14% buildspeed compared to master on Windows 64 debug > builds on my setup. As most improvements comes from change intrin.h > the impact on other platforms will not be that much....

I'm getting compile errors because size_t is getting redefined. My "forced include file" starts with: #if BUILDING_FOR_WINDOWS #define NOMINMAX /* deal with the fact that windef.h also defines BOOL */ #define BOOL WINBOOL #include <windows.h> #include <intrin.h> #undef BOOL #endif Looking at the preprocessor expansion of a typical .cpp file, I see that crtdefs.h defines size_t like this: typedef unisgned __int64 size_t; Later on, <LLVM>\lib\clang\3.6.0\includes\stddef.h defines it as: typedef unsigned int size_t; Is there some other magi...

...thon issue where open temporary files cannot be opened again. > Needed for clang-c++tests. Looks good to me. Daniel, would it be enough? > clang-missing-builtins.patch: > llvm-interrupt-builtin.patch: > > Add builtins needed to implement __debugbreak and _byteswap_ushort from > intrin.h. Before implementing everything else needed for intrin.h I need to > know if this is the correct way? I have no idea, excuse me. :( > clang-msvc10-fix-mm_malloc-error.patch: > > mm_malloc is implemented in Visual Studio 2010, this fixes the compile error > resulting from it bein...

...doc... /usr/bin/rdoc Looks curious but no problem since it's found anyway. 2. xapian-core when built with GCC: checking whether __builtin_add_overflow is declared... yes ... checking whether _addcarry_u64 is declared... no There is actually _addcarry_u64 in GCC too, but it's in x86intrin.h instead of intrin.h. This is no problem either, since it's superimposed by __builtin_add_overflow anyway. Thanks,

...ng redefined. My > "forced include file" starts with: > > #if BUILDING_FOR_WINDOWS > #define NOMINMAX > > /* deal with the fact that windef.h also defines BOOL */ > #define BOOL WINBOOL > > #include <windows.h> > #include <intrin.h> > > #undef BOOL > #endif > > Looking at the preprocessor expansion of a typical .cpp file, I > see that crtdefs.h defines size_t like this: > > typedef unisgned __int64 size_t; > > Later on, <LLVM>\lib\clang\3.6.0\includes\stddef.h d...

I tried checking out the latest llvm/clang from SVN (as of a few hours ago) and compiling it (clang 3.6.1 doesn't compile 3.7 because it fails a version check, so I repeated the technique of compiling with Microsoft C++ first, then using the resulting clang-cl.exe). It fails with a bunch of error messages along the lines of: LLVMSupport.lib(Atomic.obj) : error LNK2019: unresolved external

...alloc/malloc.h' file not found #include <malloc/malloc.h> ... CheckIncludeFile.c:1:10: fatal error: 'ndir.h' file not found #include <ndir.h> ... CheckIncludeFile.c:1:10: fatal error: 'sys/ndir.h' file not found #include <sys/ndir.h> ... fatal error: 'intrin.h' file not found These seem like tests that are expected to fail. ... The interesting test int main() { __builtin_ffs(0); return 0; } fails like this: /usr/bin/ld[...]llvm/bin/../lib/LLVMgold.so: cannot open shared object file: No such file[...] I have two questions here: Is there an...

.... My >> "forced include file" starts with: >> >> #if BUILDING_FOR_WINDOWS >> #define NOMINMAX >> >> /* deal with the fact that windef.h also defines BOOL */ >> #define BOOL WINBOOL >> >> #include <windows.h> >> #include <intrin.h> >> >> #undef BOOL >> #endif >> >> Looking at the preprocessor expansion of a typical .cpp file, I see that >> crtdefs.h defines size_t like this: >> >> typedef unisgned __int64 size_t; >> >> Later on, <LLVM>\lib\clang\3.6.0\inc...

...arcus Asteborg wrote: > 1. Build test for cmake and run the test in gitlab-ci. > 2. Disable the message box on Windows on abort that cause test hangs in CI. > 3. Build time improvement by removing unnecessary includes of stdio.h > in production code and change to a lighter header intrin.h -> > intrin0.h (windows only). Attached screenshot of measurement but it > resulted in 14% buildspeed compared to master on Windows 64 debug > builds on my setup. As most improvements comes from change intrin.h > the impact on other platforms will not be that much....

...1. Build test for cmake and run the test in gitlab-ci. OK, merged. > 2. Disable the message box on Windows on abort that cause test hangs in CI. Merged too. > 3. Build time improvement by removing unnecessary includes of stdio.h > in production code and change to a lighter header intrin.h -> > intrin0.h (windows only). Attached screenshot of measurement but it > resulted in 14% buildspeed compared to master on Windows 64 debug > builds on my setup. As most improvements comes from change intrin.h > the impact on other platforms will not be that much....