similar to: About "attempt to fix differences between x86 FPU and SSE calculations"

Olivier Tristan <o.tristan at uvi.net> ?????(?) ? ????? ?????? Fri, 21 Mar 2014 22:41:00 +0400: > Check with -mfpmath=387 to be sure that x87 FPU code is used and not some > SSE optim made by GCC I added "XIPH_ADD_CFLAGS([-mfpmath=387])" into configure.ac Still the result is different from SSE version. --------------- MSVS adds two instructions to the generated code after

Update: I have been working on this all day, and I finally got it working more or less with the pattern instruction selector... However, the generated code is not very good, and I haven't implemented the expand to calls if the target does not support these FP instructions. As an example, in the following function the sub abs and compare compiles to 13 instructions! Also it has changed the

Hello, I am trying to make the FP intrinsics (abs, sin, cos, sqrt) I've added work with the X86ISelPattern, but I'm having some difficulties understanding what needs to be done. I assume I have to add new nodetypes for the FP instructions to SelectionDAGNodes.h, and make nodes for these in SelectionDAGLowering::visitCall when I find the intrinsic... The part I don't quite

2013/10/19 Rafael Espíndola <rafael.espindola at gmail.com>: > On 19 October 2013 06:01, 罗勇刚(Yonggang Luo) <luoyonggang at gmail.com> wrote: >> I found that access llvm-mc from clang driver is impossible, and I >> want to use llvm-mc to compile assembly files, how to do that? > > Try "clang -integrated-as -c test.s" Thank you very much, I use the

All, in the light of erratum #573 I''m wondering if we need to tweak or conditionally suppress fsincos emulation. The question is whether there is any possibility for getting the emulator to hit this instruction on AMD (as no real mode emulation ought to be taking place there), i.e. whether there are places where emulation gets continued eagerly in anticipation of the need for emulation

On Wed, 16 Mar 2005, Morten Ofstad wrote: > Hello, > > I didn't get any reply to my previous mail about adding floating point > intrinsics to the X86 pattern instruction selector... And I could really need > some help. Sorry about that, it slipped through the cracks. :( > Anyway, I think my confusion was caused partly by an already > existing bug in the instruction

Hello, I didn't get any reply to my previous mail about adding floating point intrinsics to the X86 pattern instruction selector... And I could really need some help. Anyway, I think my confusion was caused partly by an already existing bug in the instruction selection for floating point compares. The case which emits code for the special case of comparing against constant 0.0 does not

Jean-Marc Valin wrote: >If you set the denoiser to "on" and the VAD to "off", what difference >does it make in CPU time? > <p>Same program, running on Athlon XP 1700+: Test 1, using VAD, but AGC, denoise off: tevek@canarsie:~/work/hms/app_conference $ time ./vad_test /tmp/demo-instruct.sw 5 reading from /tmp/demo-instruct.sw, repeating 5 times read 537760

I can confirm I get the same behavior, and that's a real bug. If you use --target=i686-pc-win32, you get COFF, and that should be a good workaround for now. There must be a conditional somewhere that isn't handling mingw correctly. On Sat, Oct 19, 2013 at 7:58 AM, 罗勇刚(Yonggang Luo) <luoyonggang at gmail.com>wrote: > 2013/10/19 Rafael Espíndola <rafael.espindola at

On 19 October 2013 06:01, 罗勇刚(Yonggang Luo) <luoyonggang at gmail.com> wrote: > I found that access llvm-mc from clang driver is impossible, and I > want to use llvm-mc to compile assembly files, how to do that? Try "clang -integrated-as -c test.s" Cheers, Rafael

I found that access llvm-mc from clang driver is impossible, and I want to use llvm-mc to compile assembly files, how to do that? H:\CI\bld\compilers\musl\src\math\i386>clang -c -v --target=i686-pc-mingw sqrt.s clang version 3.4 (trunk) Target: i686-pc-mingw Thread model: posix Selected GCC installation: "gcc" -v -c -m32 -o sqrt.o -x assembler sqrt.s clang.exe: error: unable to

Hmm, I'm not able to get those .ll files to compile if I disable SSE and I end up with SSE instructions(including sqrtpd) if I don't disable it. On Thu, Jul 18, 2013 at 10:53 PM, Peter Newman <peter at uformia.com> wrote: > Is there something specifically required to enable SSE? If it's not > detected as available (based from the target triple?) then I don't think

Hmm, maybe sse isn't being enabled so its falling back to emulating sqrt? On Thu, Jul 18, 2013 at 10:45 PM, Peter Newman <peter at uformia.com> wrote: > In the disassembly, I'm seeing three cases of > call 76719BA1 > > I am assuming this is the sqrt function as this is the only function > called in the LLVM IR. > > The code at 76719BA1 is: > >

For example, I execute the following command sequences: H:\CI\bld\compilers\musl\src\math\i386>type sqrt.s #.globl _sqrt .global sqrt #.type sqrt, at function #_sqrt: sqrt: fldl 4(%esp) fsqrt fstsw %ax sub $12,%esp fld %st(0) fstpt (%esp) mov (%esp),%ecx and $0x7ff,%ecx cmp $0x400,%ecx jnz 1f and $0x200,%eax

libFLAC for Windows compiled with GCC/MinGW can't detect SSE OS support: it can't use GCC+Linux detection code and can't use MSVC+Win32 code that uses SEH (__try/__except). So it doesn't use any SSE/SSE2/etc routines. One way to fix it is to call configure script with --enable-sse (flac will probably crash on Win95/WinNT4 but who cares). Another way is to add a new code just for

It's not possible to use ia32/*.nasm code in 64-bit compiles. There's still no 64-bit asm code in FLAC. I'm not familiar with asm too, so I wrote SSE-accelerated code using intrinsics. This code uses two new preprocessor macros: FLAC__CPU_X86_64 (analogous to FLAC__CPU_IA32) and FLAC__HAS_X86INTRIN (analogous to FLAC__HAS_NASM) Patch for cpu.c/cpu.h adds CPU features (sse3, ssse3)

That should map directly to sqrtpd which can't modify ecx. On Thu, Jul 18, 2013 at 10:27 PM, Peter Newman <peter at uformia.com> wrote: > Sorry, that should have been llvm.x86.sse2.sqrt.pd > > > On 19/07/2013 3:25 PM, Craig Topper wrote: > > What is "frep.x86.sse2.sqrt.pd". I'm only familiar with things prefixed > with "llvm.x86". >

Hi Guys, I know that FLAC format is currently limited to 8 channels but I was wondering if this hard limitation of the format or if it can be easily circumvented if the flac library is compiled with other settings and/or the software using it don't mind it Thanks ! -- Olivier Tristan Research & Development www.uvi.net

In the disassembly, I'm seeing three cases of call 76719BA1 I am assuming this is the sqrt function as this is the only function called in the LLVM IR. The code at 76719BA1 is: 76719BA1 push ebp 76719BA2 mov ebp,esp 76719BA4 sub esp,20h 76719BA7 and esp,0FFFFFFF0h 76719BAA fld st(0) 76719BAC fst dword ptr [esp+18h] 76719BB0 fistp

On 22 March 2016 at 11:34, James Molloy <James.Molloy at arm.com> wrote: > I don’t think this part is right. The denormal flag would have to be set by > whatever code generates the FP instruction, which would be Clang’s codegen > layer. So the if (Darwin) would be there, not in TTI. Right, I meant the information to set/not set would be in TTI, not the actual setting. I don't