similar to: [PATCH 4/5] SIMD: accelerate decoding of 16-bit FLAC

This patch removes FLAC__lpc_restore_signal_16_intrin_sse2(). It's faster than C code, but not faster than MMX-accelerated ASM functions. It's also slower than the new SSE4.1 functions that were added by the previous patch. So this function wasn't very useful before, and now it's even less useful. I don't see a reason to keep it. -------------- next part -------------- A

This patch accelerates decoding of non-Subset 24-bit FLAC files (where lpc_order > 12). (The improved function is FLAC__lpc_restore_signal_wide_intrin_sse41(). It requires SSE4.1 and it's used only by 32-bit libFLAC) -------------- next part -------------- A non-text attachment was scrubbed... Name: 03_wide_decode.patch Type: application/octet-stream Size: 5502 bytes Desc: not available

Hi Guys, In stream_decoder.c when assigning lpc restore function, only IA32 processor benefits from SS2 and SSE4.1 optimization. Shouldn't it be the case for x86_64 processor as well ? Thanks, -- Olivier TRISTAN uvi.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20140311/1d49b5c2/attachment.htm

Is it possible to see the source code of the open-sourced SVML? The diff file does not include the library. I searched the Internet but I could not find. Regards, Naoki Shibata On 2016/07/15 13:55, Tian, Xinmin wrote: > Naoki, > > Intel is planning open-source SVML library (most of them if it not 100%), 6 functions of SVML are open sourced for GCC and LLVM already. But, Intel SVML

CCing Zach, who did a lot of the VS 2017 support work (AFAIK), and Reid, who's the general Microsoft support overlord. By full support for VS 2017, do you mean within the IDE itself? I haven't ever used clang from within the VS IDE, so I can't speak to that. All non-IDE stuff should work though, as far as I know. Which compiler options/switches specifically are missing? Filing bugs

Hi all, Okay, the point is whether Intel will publish the source code for their SVML. If Intel will make SVML open-source, there would be not much advantage in incorporating SLEEF into LLVM, since it would be also fairly easy to port SVML to other architectures. If Intel will not open-source SVML, then there could be advantage in using SLEEF for x86 by inlining the functions. Is it possible

At Microsoft, we believe that we gain a competitive advantage by making the Visual Studio versioning story as complicated as possible. To wit: The compiler in the first VS 2015 release was version 19.00. For each update/hotfix release, we bumped that version by .01. When VS 2017 was released, we decided to keep the major compiler version the same to signify backwards-binary-compatibility with the

i want to integrate a C source JITer into my application but the resulting executables are too large is it possible to reduce the resulting libs/exe some way? current VS2017/svn build example: llvm-build\Release\bin\clang-interpreter.exe ~36MB for now (that can change later) - i want to jit simple c-code - no std library or something - x64 only - no deep/full architecture optimization needed -

my build environment: Win7 x64 VStudio 2017 Community Edition 15.8.4 (latest) CMake 3.12.1 (x86) git 2.19.0 (latest, x64) Python 2.7.2 (x86) my build steps: open VS2017 x64 developer command prompt cd D:\projects\fun\jit_tests mkdir llvm cd llvm git clone https://github.com/llvm-mirror/llvm mkdir llvm-build cd llvm-build cmake -G "Visual Studio 15 2017 Win64" -DBUILD_SHARED_LIBS=ON

Hello, Thank you very much for quick response. I need only xapian-core. As I wrote on my case compilation with Visual Studio 2015 successful, just I have runtime errors, while the same code on LINUX runs fine. I'll try the hints from (https://trac.xapian.org/browser/git/xapian-core/INSTALL?rev=RELEASE/1.4#L54) and maybe to migrate my project to VS2017 and test it again. If I understand

Hi everyone, I think that everyone is on the same page. We'll put together a patch for review. One remaining question: There seem two potential homes for this library: parallel_libs and compiler-rt. Opinions on where the vectorized math functions should live? My inclination is to target it for the new parallel_libs project, in part because I feel like compiler-rt has too many things grouped

Yes, Thank you. I'll follow up with the AVX code and tests for pitch code. Radu -----Original Message----- From: opus-bounces at xiph.org [mailto:opus-bounces at xiph.org] On Behalf Of Timothy B. Terriberry Sent: Thursday, November 5, 2015 10:31 AM To: opus at xiph.org Subject: Re: [opus] AVX Optimizations Velea, Radu wrote: > I've created a pull request[1] to enable configuration

Thank you very much,It works! And some Q&A I meet,may help somebody: 1. If zlib build with 32bit,should use MSVC's 'vcvars32.bat'; 2. Add '-Z7' to CXXFLAGS can release *.pdb file for VS2017 'Step Into' debug, such as: CXXFLAGS="-EHsc -Z7"; 3. If Somebody write a demo in VS2017 3.1 change libxapian.a's name to libxapian.lib; 3.2 make sure the

By default, FLAC requires ogg library. Support of old versions of Visual Studio was removed from libogg code about 2 years ago: https://git.xiph.org/?p=ogg.git;a=commit;h=18c401c6bc8814d06f3ae53ebf5d4399f90871cc libogg 1.3.3 (released 2017-11-07) cannot be built with MSVS 2005/2008 anymore. Are there any developers that want to use libFLAC in their programs and still use Visual Studio 2005 or

Viswenath, My patch should be against the tip, but it?s the very recent tip, including some changes this past Friday (27 Feb). I mentioned in the IRC room a problem I discovered in creating my patch, and then later improved the fix Tim had made for the problem. Where do you get conflicts merging it to tip? In terms of merging, you posted your patch before I posted mine, so probably I should be

Hi, When setting -mattr option on X86, I would like to treat MMX separately from SSE levels. This would allow a client who sets the attributes directly to set the SSE level independent of MMX, e.g., llc -march=x86 -mattr=sse41, one would get sse4.1 with mmx disabled while llc -march=x86 -mattr=mmx -mattr=sse42 will get mmx and sse42. If anyone objects to this change, please let me

Hi everyone, After much waiting, Opus 1.1.1 is finally here. The main changes are: - x86 SSE, SSE2 and SSE4.1 optimizations contributed by Cisco, - MIPS optimizations contributed by Imagination Technologies, - ARM Neon optimizations contributed by Linaro and ARM, - many architecture-independent optimizations, - memory footprint reductions, and - several minor bug fixes. The quality of the

The attached patch cleans up Opus's x86 intrinsics configury. It: * Makes ?enable-intrinsics work with clang and other non-GCC compilers * Enables RTCD for the floating-point-mode SSE code in Celt. * Disables use of RTCD in cases where the compiler targets an instruction set by default. * Enables the SSE4.1 Silk optimizations that apply to the common parts of Silk when Opus is built in

On Mar 3, 2015, at 11:08 PM, Viswanath Puttagunta <viswanath.puttagunta at linaro.org<mailto:viswanath.puttagunta at linaro.org>> wrote: On 3 March 2015 at 21:59, Jonathan Lennox <jonathan at vidyo.com<mailto:jonathan at vidyo.com>> wrote: Viswenath, My patch should be against the tip, but it?s the very recent tip, including some changes this past Friday (27 Feb). I

Hi Chandler, all, Why aren't the vector [zs]extloads introduced by SSE4.1/AVX2 declared legal? Is it a simple oversight, or did I miss a deeper reason? While cleaning up PMOV*X patterns, I stumbled upon this braindead testcase: %0 = load <8 x i8>* %src, align 1 %1 = zext <8 x i8> %0 to <8 x i16> turning into: pmovzxbw (%rsi), %xmm0