similar to: [LLVMdev] udis86 sse4.1 and 4.2?

Hi, all. I posted this message to libvir-list last night, but just realized that was geared toward development rather than support. Apologies to those who are subscribed to both for the dupe. I'm having a weird problem where libvirt/qemu/kvm won't let me use the model processor I have defined in my domain's config file. Instead, I get the error message in libvirtd.log that:

Debug build on x86_64 with`--with-udis86=<path>' option to 'configure' seems broken. Configure command line: ./configure --disable-optimized --enable-assertions --enable-debug-runtime --enable-debug-symbols --enable-jit --enable-pic --enable-targets=x86_64 --with-udis86=/somepath/udis86/udis86-1.7 At least 2 issues: (1) '-L/somepath/udis86/udis86-1.7' is added to the

On Mon, Mar 03, 2014 at 02:15:43PM +0000, Struan Bartlett wrote: > > > On 03/03/2014 13:42, Martin Kletzander wrote: > > On Mon, Mar 03, 2014 at 11:15:51AM +0000, Struan Bartlett wrote: > >> On 03/03/2014 10:55, Martin Kletzander wrote: > >>> On Mon, Mar 03, 2014 at 10:47:03AM +0000, Struan Bartlett wrote: > >>>> On 03/03/2014 10:44, Martin

On 10/27/2013 05:57 PM ken wrote: > One laptop I'm looking at buying offers these CPU options: > > * 4 Generation Intel? Core? i7-4700MQ Processor ( 2.4 GHz 6MB L3 Cache - > 4 Cores plus Hyperthreading ) > > * 4th Generation Intel? Core? i7-4800MQ Processor ( 2.7 GHz 6MB L3 Cache > - 4 Cores plus Hyperthreading ) > > * 4th Generation Intel? Core? i7-4900MQ Processor

I am using a debian 9 guest, hosted on a ESXi platform with nested virtualisation enabled. On this debian 9 guest when I run libguesfs-test-tool, it fails with an error: "qemu-system-x86_64: /build/qemu-DqynNa/qemu-2.8+dfsg/target-i386/kvm.c:1805: kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed." Instead when I use a wrapper script and hook it with the env

Current sources (git-b1b6caf) were compiled with GCC 4.8.2 and GCC 4.9.0 with various -msseN options (the default is -msse2). Then I took two WAV files (one is 16-bit and the other is 24-bit) and compressed them using best compression mode. The results are in the table below. (please remember that the resulting value is an encoding time, not encoding speed) CPU: Intel Core i7 950 (up to SSE4.2)

I've been working on adding AVX to LLVM and have run across a number of questions. Here's the first one. In some ways AVX is "just another" SSE level. Having AVX implies you have SSE1-SSE4.2. However AVX is very different from SSE and there are a number of sub-features which may or may not be available on various implementations. So right now I've done this: def

On Apr 30, 2009, at 3:02 PM, David Greene wrote: > I've been working on adding AVX to LLVM and have run across a number > of > questions. Here's the first one. > > In some ways AVX is "just another" SSE level. Having AVX implies > you have > SSE1-SSE4.2. However AVX is very different from SSE and there are a > number > of sub-features which

This patch accelerates FLAC__lpc_compute_autocorrelation_intrin_sse_lag_NN routines for AMD and newer Intel CPUs. But it's slower on older Intel CPUs. ('Newer Intel CPUs' means Core i aka Nehalem and newer) According to tests at HA: <http://www.hydrogenaud.io/forums/index.php?s=&showtopic=101082&view=findpost&p=870753> CPU flac -5 flac -8

Hello r-help, I am having trouble installing the add-on package gstat. I suspect (but I'm not sure) that the trouble may be that it runs all the checks for gcc, then uses Intel's compiler to actually compile. I have not been able to successfully force it to use gcc to test that theory. R CMD INSTALL and R.version() output follow below; any help greatly appreciated! -Tim -- Timothy

On 03/03/2014 13:42, Martin Kletzander wrote: > On Mon, Mar 03, 2014 at 11:15:51AM +0000, Struan Bartlett wrote: >> On 03/03/2014 10:55, Martin Kletzander wrote: >>> On Mon, Mar 03, 2014 at 10:47:03AM +0000, Struan Bartlett wrote: >>>> On 03/03/2014 10:44, Martin Kletzander wrote: >>>>> On Mon, Mar 03, 2014 at 10:30:11AM +0000, Struan Bartlett wrote:

On 30-Apr-09, at 6:38 PM, Dan Gohman wrote: > On Apr 30, 2009, at 3:02 PM, David Greene wrote: >> As I've been going along I've added feature flags for SSE4a and >> SSE5. These >> really do need to be separate feature flags because having SSE4a and/ >> or SSE5 >> does not imply that you have SSE4.2 or SSE4.1. So they can't be >> part of the

The first patch adds SSE4.1/SSE4.2 detection. The second patch removes union data in struct FLAC__CPUInfo and replaces it with #ifdefs. Reason: currently it's possible to set or get data.ia32.sse3 value from x86-64 code, etc. It's a potential source of errors (at least that's true for me). (the 2nd patch requires the 1st to be applied) -------------- next part -------------- A

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

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

Thanks Reid - I'm on Windows. I guess I just assumed I was missing something obvious in how to hook up the JIT and disassembler! Given the nice looking disassembly code I found, I thought people would be doing it all the time :-) b. On Tue, Jul 6, 2010 at 8:41 PM, Reid Kleckner <reid.kleckner at gmail.com> wrote: > If you're on a recent flavor of Linux, you may be able to just

On Nov 25, 2013, at 4:40 PM, Dan Gohman <dan433584 at gmail.com> wrote: > Hello llvm-dev, > > Following up on the "CodeGen Context" discussion that was started, attached is patch which implements a pretty minimal skeleton of a CGContext implementation. The goal is to allow the newly added subtarget attributes on functions to be made available to codegen so that codegen

Thanks for all the hints everyone. Based on your suggestion, O.J., I've added code to toy.cpp from the tutorial to disassemble. ready> 1+1; ready> movabsq $140737353367568, %rax movsd (%rax), %xmm0 ret Evaluated to 2.000000 ready> Which looks correct by inspection - printing the byte array to stdout and feeding it to llvm-mc offline produces the same code as one would also

If you're on a recent flavor of Linux, you may be able to just go into gdb and type "disas <pointer-to-JITed-code>". More detail here: http://llvm.org/docs/DebuggingJITedCode.html If you still want to do it programmatically, I think you might be stuck. IIRC the length known by the JIT memory allocator is an overestimate (it's rounded up for alignment), so the

Hi, With the new llvm-mc code for disassembling, what is the recommended way to disassemble the final code produced by a JIT compiler backend? (Eg. in the toy.cpp example from the tutorial). I can get the void* for the final code, but I don't know its length - superficially at least it appears I need to know the length to disassemble it as a buffer? Thanks b.