search for: intrins

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%

> 1. Compile Error with regular mode (FIXED_POINT undefined) at lsp.c line 104 > static inline spx_word16_t spx_cos(spx_word16_t x) . VS6 does not like > the inline keyword here. Removing it allows compiling. > > same with cb_search_sse.h line 34. It seems like your compiler simply doesn't like "inline". I suggest doing a -Dinline= which is what autoconf

Here are our notes on 1.1.4 testing on Windows 1. Compile Error with regular mode (FIXED_POINT undefined) at lsp.c line 104 static inline spx_word16_t spx_cos(spx_word16_t x) . VS6 does not like the inline keyword here. Removing it allows compiling. same with cb_search_sse.h line 34. 2. Compile Error with quant_lsp.c line 55. M_PI is undefined. Either it needs to be included

> 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

Jean-Marc, 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. Aron Rosenberg SightSpeed At 08:54 PM 1/21/2004, you wrote: > > 1. Compile Error with regular mode (FIXED_POINT undefined)

...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=ugnh...

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 complete ci feedback, the intrin0.h

On Sat, Dec 02, 2023 at 10:24:57PM +0300, Vitaly Chikunov wrote: > JFYI. I am not sure it's worth reporting but, when building 2.5.5 for ALT Talking of small inconsistencies, 2.5.5 isn't a Xapian version... > I noticed small inconsistencies in configure output. > > 1. xapian-binding: > > checking for /usr/bin/rdoc... no > checking for rdoc... /usr/bin/rdoc >

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>

3, no good catch attached is an updated patch //Marcus ________________________________ From: Jean-Marc Valin <jmvalin at jmvalin.ca> Sent: Thursday, June 11, 2020 10:49 To: Marcus Asteborg <xnorpx at outlook.com>; opus at xiph.org <opus at xiph.org> Subject: Re: [opus] Misc patches On 2020-06-08 01:39, Marcus Asteborg wrote: > 1. Build test for cmake and run the test in

...tdefs.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 magic I need to do to get these to work? I'm also seeing a bunch of errors like this having to do with intrinsics: 1> In file included from C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\algorithm:6: 1> In file included from C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory:6: 1> In file included from C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC...

Hello Erik, Thank you to work. I have not checked to build them, though, I can tell you some comments, excuse me. * General - Please post patches to cfe-commits and to llvm-commits, too. (IMHO it would not be needed to split articles apart each lists as long as each would be related.) - If you can, please attach files w/o CRLF(dos encodings), or with attached text/plain. - You may

Hi, JFYI. I am not sure it's worth reporting but, when building 2.5.5 for ALT I noticed small inconsistencies in configure output. 1. xapian-binding: checking for /usr/bin/rdoc... no checking for rdoc... /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 ...

...ize_t; > > Later on, <LLVM>\lib\clang\3.6.0\includes\stddef.h defines it as: > > typedef unsigned int size_t; > > Is there some other magic I need to do to get these to work? > > I'm also seeing a bunch of errors like this having to do with > intrinsics: > > 1> In file included from C:\Program Files (x86)\Microsoft Visual > Studio 12.0\VC\include\algorithm:6: > 1> In file included from C:\Program Files (x86)\Microsoft Visual > Studio 12.0\VC\include\xmemory:6: > 1> In file included from C:\Progr...

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

On Fri, Sep 16, 2016 at 10:54 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > Can you look for the specific errors in the CMake log and error files? > > CMake is very good at not presenting the real issue… > Here it is trying to build very simple programs to check features > availability. Like: > > #include <strings.h> > int main() { ffs(0); return 0;

...>> >> Later on, <LLVM>\lib\clang\3.6.0\includes\stddef.h defines it as: >> >> typedef unsigned int size_t; >> >> Is there some other magic I need to do to get these to work? >> >> I'm also seeing a bunch of errors like this having to do with intrinsics: >> >> 1> In file included from C:\Program Files (x86)\Microsoft Visual Studio >> 12.0\VC\include\algorithm:6: >> 1> In file included from C:\Program Files (x86)\Microsoft Visual Studio >> 12.0\VC\include\xmemory:6: >> 1> In file included from C:\P...

Hi Marcus, On 2020-06-08 01:39, Marcus 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

On 2020-06-08 01:39, Marcus Asteborg wrote: > 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).