search for: mmx

On Mon, Aug 31, 2020 at 3:02 PM Eli Friedman <efriedma at quicinc.com> wrote: > Broadly speaking, I see two problems with implicitly enabling MMX > emulation on a target that has SSE2: > > > > 1. The interaction with inline asm. Inline asm can still have MMX > operands/results/clobbers, and can still put the processor in MMX mode. If > code is mixing MMX intrinsics and inline asm, there could be a significant...

Hi, I''ve a quad-core x86_64 machine (Intel Xeon), with sse/mmx support. However, I want to disable sse/mmx support from HVM guests. How can I do this? Also, is it reasonable to expect illegal instruction fault in non-root VMX mode if a guest VM runs an application with sse/mmx instructions? Thanks, Ashish _______________________________________________ Xen-d...

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

I recently diagnosed a bug in someone else's software, which turned out to be due to incorrect MMX intrinsics usage: if you use any of the x86 intrinsics that accept or return __m64 values, then you, the *programmer* are required to call _mm_empty() before using any x87 floating point instructions or leaving the function. I was aware that this was required at the assembly-level, but not that the...

...s LLVM for dynamic code generation, and I noticed a major performance regression when upgrading from LLVM 2.8 to 3.0-rc1 (LLVM 2.9 didn't support Win64 so I skipped it entirely). I found out that the performance regression is due to removing support for lowering 64-bit vector operations to MMX, and using SSE2 instead. My code uses a mix of MMX intrinsics and v4i16 operations, so it ping-pongs back and forth between MMX and SSE2 instructions in the generated code. To get more optimal code, I see three options, and I was wondering if someone could share some advice on which approach yo...

...-elim"= "true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-nans-fp-ma th"="false" "stack-protector-buffer-size"="8" "target-cpu"="pentium4" "target-fe atures"="+mmx,-sse" "unsafe-fp-math"="false" "use-soft-float"="false" } The attributes indicate to allow mmx, disallow sse, so this certainly looks like it might work. I don't know whether work has been done to specifically do something special for this combinati...

Hello, attached is a gzipped patch file to the lib/mcomp.c source file of theora (as of AnonCVS current version) that implements MMX and extended-MMX optimizations in the most frequently used functions of the encoder (as shown by gprof). This is more a proof of concept than a real request for inclusion into the source tree. My personal intent was more to look deeper into the MMX instruction set and/or GCC and/or Theora than a r...

Hi Nicolas, > I found out that the performance regression is due to removing support > for lowering 64-bit vector operations to MMX, and using SSE2 instead. My > code uses a mix of MMX intrinsics and v4i16 operations, so it ping-pongs > back and forth between MMX and SSE2 instructions in the generated code. > > To get more optimal code, I see three options, and I was wondering if > someone could share some advice...

Hi all, I have a sample test case : $ cat 1.c int foo(int x, int y){ int z = x + y; return z/2; } I tried to get its IR form with clang providing subtarget feature as mmx for target x86_64 $ clang -O3 -mmmx 1.c -S -emit-llvm in the IR generated i can see the subtarget-features as function attribute : "target-features"="+mmx" In the SelectionDAG phase in file "X86ISelLowering.cpp", i checked in one of the function what is the subtar...

...generation, and I noticed a major performance regression when upgrading > from LLVM 2.8 to 3.0-rc1 (LLVM 2.9 didn't support Win64 so I skipped it > entirely). > > I found out that the performance regression is due to removing support > for lowering 64-bit vector operations to MMX, and using SSE2 instead. My > code uses a mix of MMX intrinsics and v4i16 operations, so it ping-pongs > back and forth between MMX and SSE2 instructions in the generated code. > > To get more optimal code, I see three options, and I was wondering if > someone could share some ad...

On Wed, Sep 8, 2010 at 12:35 AM, Nicolas Capens <nicolas.capens at gmail.com> wrote: > Hi Chris, > > It's not broken, but the performance is crippled. > > I noticed that the code still contains some MMX instructions, but several > operations get expanded (apparently swizzling and such get expanded to a > large number of byte moves). I think some changes related to MMX landed before 2.8 branched which shouldn't have... please file a bug. > I could use intrinsics, but they wouldn'...

I'm working on changing the MMX implementation to use intrinsics in all cases, which should stop various optimization passes from creating MMX instructions that screw up the x87 stack. Right now the MMX instructions are split between X86InstrMMX.td and X86InstrSSE.td, presumably on the historical grounds that some of th...

...p 8, 2010, at 7:24 AM, Eli Friedman wrote: > On Wed, Sep 8, 2010 at 12:35 AM, Nicolas Capens > <nicolas.capens at gmail.com> wrote: >> Hi Chris, >> >> It's not broken, but the performance is crippled. >> >> I noticed that the code still contains some MMX instructions, but several >> operations get expanded (apparently swizzling and such get expanded to a >> large number of byte moves). > > I think some changes related to MMX landed before 2.8 branched which > shouldn't have... please file a bug. Right. There should be no...

...I noticed a major performance regression when upgrading >> from LLVM 2.8 to 3.0-rc1 (LLVM 2.9 didn't support Win64 so I skipped it >> entirely). >> >> I found out that the performance regression is due to removing support >> for lowering 64-bit vector operations to MMX, and using SSE2 instead. My >> code uses a mix of MMX intrinsics and v4i16 operations, so it ping-pongs >> back and forth between MMX and SSE2 instructions in the generated code. >> >> To get more optimal code, I see three options, and I was wondering if >> someone cou...

On Sep 7, 2010, at 7:45 AM, Nicolas Capens wrote: > Hi all, > > I've tested a recent revision and noticed that using 64-bit vectors became very slow. It looks like they are expanded to non-MMX instructions to avoid breaking code which does not clear the MMX state using emms? > > For my project I'm already manually inserting emms instructions in the right places, so I'd really like 64-bit vector operations to be lowered to MMX instructions for best performance. So is there...

This thread confuses me. I thought Chris said that LLVM 2.8 will not lower generic vectors to MMX because it breaks x87 code, and I didn't see an answer to your question about a switch to tell the code generator otherwise. However, you're complaining that MMX performance is subpar, even though LLVM 2.8 isn't supposed to generate MMX instructions. Can someone clarify the situation...

...> > > > Kevin > > > > *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On > Behalf Of *suyog sarda > *Sent:* Thursday, April 09, 2015 11:27 AM > *To:* LLVM Developers Mailing List; David Majnemer; Sanjay Patel > *Subject:* [LLVMdev] MMX/SSE subtarget feature in IR > > > > Hi all, > > > > I have a sample test case : > > > > $ cat 1.c > > > > int foo(int x, int y){ > > int z = x + y; > > return z/2; > > } > > > > I tried to get its IR form with clang p...

LLVM isn't going to stop generating MMX instructions all together. We can't do that. :-) If the user specifically wants MMX (by, say, using the builtins), we have to support that still. The plan to cease generating MMX for generic vectors is a work-in-progress right now. It's not in 2.8. -bw On Sep 21, 2010, at 4:24 PM, Reid Kl...

On Sep 21, 2010, at 5:30 PMPDT, Bill Wendling wrote: > LLVM isn't going to stop generating MMX instructions all together. We can't do that. :-) If the user specifically wants MMX (by, say, using the builtins), we have to support that still. The plan to cease generating MMX for generic vectors is a work-in-progress right now. It's not in 2.8. > > -bw Right, early on there was...

...or the 2.8 branch. > > The real problem is that the code above it which checks for > isUNPCK[L|H]_v_undef_Mask cases is only for when OptForSize is true. It > assumes that otherwise things can get lowered to PSHUFD (which is true for > v4i32 and v4f32 but nothing else - in particular MMX operations). > > I'll file a bug now... > > Nicolas > > > -----Original Message----- > From: Dale Johannesen [mailto:dalej at apple.com] > Sent: Wednesday, September 22, 2010 2:37 > To: Bill Wendling > Cc: Dale Johannesen; Reid Kleckner; Nicolas Capens; LLVM Dev...