similar to: Heads Up: gcc-4.6 -march=corei7 -mtune=corei7 doesn't work

Hi Varun, Have you tried your experiment with icc by any chance? The MCJIT component does not assume that you will be executing the generated code on the host system because it can be used to generate code for external targets. However, you can specify the CPU by calling setCPU() on the EngineBuilder object before creating your execution engine. (You can use sys::getHostCPUName() to figure out

Hi Varun, I see the point of your question, but I'm not the best person to answer from that perspective. Nadav Rotem is the owner of the x86 backend, and he can probably give you a more complete answer than I could. Thanks, Andy From: Varun Agrawal [mailto:vagrawal at cs.stonybrook.edu] Sent: Friday, October 11, 2013 8:48 PM To: Kaylor, Andrew; llvmdev at cs.uiuc.edu Subject: RE: Building

Hi Andrew, I think I diluted my question. My question was not related to MCJIT. I ran the following 4 scenarios: (1)gcc -mcpu=corei7 tetris.c -o tetris (2)gcc -mcpu=athlon64 tetris.c -o tetris (3)clang -march=corei7 tetris.c -o tetris (4)clang -march=athlon64 tetris.c -o tetris In (1) and (2), I see difference in order of instructions in the output binaries, which I expected because every CPU

Hi, I am using the LLVM JIT infrastructure (MCJIT). I wanted to see if there are any performance gains as the compiler can detect the target CPU at runtime. But, I didn't see any improvement (I compile with -no-mmx and -no-sse). I then tried an experiment, where I compiled the program with clang-3.3, with and without specifying the target cpu as "corei7". I was shocked to see that

Why does GCC produce faster code using "-march=pentium2 -mtune=pentium4" on a Pentium 4 chip versus plain -march=pentium4? Try it... CPUTYPE=pentium2 CFLAGS+= -mtune=pentium4 COPTFLAGS+= -mtune=pentium4 -- BSD Podcasts @ http://bsdtalk.blogspot.com/

Hello, Depending on how I extract integer lanes from an x86_64 xmm register, the backend may spill that register in order to load scalars. The effect was observed on two targets: corei7-avx and btver1 (I haven't checked other targets). Here's a test case with spilling/no-spilling code put on conditional compile: #if __SSE4_1__ != 0 #include <smmintrin.h> #else #include

Which options are you seeing that cause the largest difference, and on which targets? As Chandler mentioned there has been a large amount of variation in x86 targets, and there are certain optimizations that can be done, on say a Pentium (scheduling instructions which are pairable and non-dependent so the U and V pipelines are saturated without contention, for example) that don't make sense

I have been doing some benchmarking on x86 using llvm 2.9 with the llvm-gcc 4.2 front end. I noticed that the -march and -mtune options make a significant positive difference in x86-32 mode but hardly make any difference in x86-64 mode. The small difference that I am measuring when the target is x86-64 could easily be random variation, while for the x86-32 target I am measuring a huge difference

Hello. I am trying to build R on Windows. It appears that my build passes the various "make checks" (unless I missed some error) and running Rterm seems to work fine whereas Rgui has an immediate error stating " AppName: rgui.exe AppVer: 2.150.58871.0 ModName: rzlib.dll ModVer: 0.0.0.0 Offset: 0000a9e5 The taskbar still works, but the console window has nothing in it, and

On 5/7/2012 12:21 AM, Bendersky, Eli wrote: <snip> > > MCJIT is functional in trunk (and the 3.1 branch). While it doesn't include all the features of the old JIT quite yet, it's complete enough to pass all of JIT's execution tests on Linux and Mac OS X (no Windows yet). As for directions on how to enable it, follow the path of the "use-mcjit" flag passed to lli

On Mon, Jan 16, 2012 at 12:29 AM, Ghassan Shobaki <ghassan_shobaki at yahoo.com > wrote: > Let me describe more precisely what I am doing and why the results I got > may help improve LLVM's performance on modern x86-64 processors regardless > of the front end (GCC, Clang or DragonEgg). > > I am running ALL my tests on an Intel Xeon E5540 processor, which is an > x86-64

Hi Chandler, Thanks for fixing the problem with the insertps mask. Generally the new shuffle lowering looks promising, however there are some cases where the codegen is now worse causing runtime performance regressions in some of our internal codebase. You have already mentioned how the new shuffle lowering is missing some features; for example, you explicitly said that we currently lack of

Wow. Somehow, I forgot about vbroadcast and vpbroadcast. =[ Sorry about that. I'll fix those. On Fri, Sep 26, 2014 at 3:39 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com > wrote: > Hi Chandler, > > Here is another test. > > When looking at the AVX codegen, I noticed that, when using the new > shuffle lowering, we no longer emit a single vbroadcastss in the case

> I promise I'll do the review of your code after that. Tim, I don’t want to push too much. But since there’s 3.4 release on the horizon, maybe you could find a moment review this patch. Especially Haswell is all there since few months. Cheers, -- Adam --- lib/Support/Host.cpp | 8 ++++++++ lib/Target/X86/X86Subtarget.cpp | 3 ++- 2 files changed, 10 insertions(+), 1

> On 5/7/2012 12:21 AM, Bendersky, Eli wrote: > <snip> > > > > MCJIT is functional in trunk (and the 3.1 branch). While it doesn't include all > the features of the old JIT quite yet, it's complete enough to pass all of JIT's > execution tests on Linux and Mac OS X (no Windows yet). As for directions > on how to enable it, follow the path of the

Johannes, I tried the last one and it gave me this: error: unknown target CPU 'XYZ' note: valid target CPU values are: nocona, core2, penryn, bonnell, atom, silvermont, slm, goldmont, goldmont-plus, tremont, nehalem, corei7, westmere, sandybridge, corei7-avx, ivybridge, core-avx-i, haswell, core-avx2, broadwell, skylake, skylake-avx512, skx, cascadelake,

On 5/7/2012 10:17 PM, Bendersky, Eli wrote: <snip> >>> $lli -entry-function="ISimEngine_GetVersion" -use-mcjit libengine.bc >>> LLVM ERROR: Inline asm not supported by this streamer because we don't >>> have an asm parser for this target >> >> I also tried other variations of the call with the same result: >>> $lli

Hi Josh, This line works for me: opt file.ll -loop-vectorize -S -o - -mtriple=x86_64 -mcpu=corei7-avx -debug You need to specify the triple on the command line if it is not inside the module. Thanks, Nadav On May 9, 2013, at 5:53 PM, Joshua Klontz <josh.klontz at gmail.com> wrote: > Nadav, > > Please forgive my ignorance, but 'opt -mcpu=corei7 -loop-vectorize -S

I just installed steam+TMN and it seems to run quite well apart from sound. I tried switching to OSS and got not sound while on ALSA I get the occasional "click" and thats about it. Other software I have run through wine is WAR beta and WoW both of which play sound fine, so I suspect maybe Steam is holding up the sound device or something? I am on Ubuntu Hardy. I also used winetricks

Let me describe more precisely what I am doing and why the results I got may help improve LLVM's performance on modern x86-64 processors regardless of the front end (GCC, Clang or DragonEgg). I am running ALL my tests on an Intel Xeon E5540 processor, which is an x86-64 Nehalem processor. The OS is a 64-bit version of Ubuntu. So, I am running all my tests on the same x86-64 machine and am