similar to: Proposal to remove MMX support.

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

Hi Bill, Comments inline: On 24/10/2011 9:50 PM, Bill Wendling wrote: > On Oct 20, 2011, at 8:42 AM, Nicolas Capens wrote: > >> Hi all, >> >> I'm working on a graphics project which uses 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

On Oct 20, 2011, at 8:42 AM, Nicolas Capens wrote: > Hi all, > > I'm working on a graphics project which uses 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

Hi all, I'm working on a graphics project which uses 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

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

On Oct 26, 2011, at 1:18 PM, Nicolas Capens wrote: > On 24/10/2011 9:50 PM, Bill Wendling wrote: >> On Oct 20, 2011, at 8:42 AM, Nicolas Capens wrote: >> >>> Hi all, >>> >>> I'm working on a graphics project which uses LLVM for dynamic code >>> generation, and I noticed a major performance regression when upgrading >>> from LLVM

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

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

On Jul 1, 2011, at 2:43 PM, Alistair Lynn wrote: > Hi Andrew- > >> fatal error: error in backend: SSE2 register return with SSE2 disabled > > Is this for 32-bit or 64-bit x86? 64-bit x86. > If it's the latter, the ABI demands > that the return value in this case is in xmm0 - SSE is required. > Well -no-sse -mno-mmx works for EFI as it is pre-boot firmware and

> This is a matter of presentation, but some of the "GCC extensions" are > standard C99 (now, at least). I noticed long long, C++-style comments > and designated initializers. > > I have plenty of complaints about the GCC documentation you're > pointing at, but this probably isn't the right forum for that. I do > think dropping "as fast as

Hi Andrew- > fatal error: error in backend: SSE2 register return with SSE2 disabled Is this for 32-bit or 64-bit x86? If it's the latter, the ABI demands that the return value in this case is in xmm0 - SSE is required. Alistair

On Sep 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

On Feb 10, 2008, at 11:26 PM, Chris Lattner wrote: >> This is a matter of presentation, but some of the "GCC extensions" >> are >> standard C99 (now, at least). I noticed long long, C++-style >> comments >> and designated initializers. >> >> I have plenty of complaints about the GCC documentation you're >> pointing at, but this

On Aug 31, 2010, at 11:18 AM, Argyrios Kyrtzidis wrote: > Hi, > > I've attached 2 .ll files which are supposed to be equivalent but 'unopt-fail.ll' causes a crash in webkit's test suite while 'unopt-pass.ll' does not. I can't give more details about the crash, when I run the crashing test it in isolation it passes, when I run the full suite it crashes; it

Thanks Kevin for the reply. I got the point now :) On 10 Apr 2015 00:18, "Smith, Kevin B" <kevin.b.smith at intel.com> wrote: > For x86_64 ABI, a minimum feature set of SSE2 is required. > > > > Kevin > > > > *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On > Behalf Of *suyog sarda > *Sent:* Thursday, April 09,

On Aug 31, 2010, at 10:19 PM, Chris Lattner wrote: > > Hi Argiris, > > The real problem here is that the X86 backend is turning datatypes like <1 x i64> into MMX operations, but doesn't do so in a safe way (it's not inserting the requisite EMMS instructions). After discussing this with Dale and Bill, the right fix is to stop mapping generic vectors onto MMX operations.

On Apr 14, 2011, at 12:47 PM, Eli Friedman wrote: >> I looked at the program using a debugger, and the pfadd instruction is >> executed correctly and the MMX register contains the correct values. >> The code that prepares the stack for the printf call seems to be >> messing it up. > > I would call that "user error"; basically, using MMX instructions >

Hi, I’ve come back and updated my llvm toolset with modern code (my branch was about 1-2 years old) and now the llvm IR files produced by my front end no longer compile with llc. Here is a sample of llvm ir produced by my front end (it’s a standard version 3.1 build of swift from the swift.org open source website). ; ModuleID = 'main.ll' source_filename = "main.ll" target

On Fri, Jul 17, 2009 at 04:41:55PM -0700, Eli Friedman wrote: > On Fri, Jul 17, 2009 at 4:14 PM, Jonathan Gray<jsg at goblin.cx> wrote: > > This seems to go against notes such as > > http://clang.llvm.org/features.html#performance > > which claim clang is signifcantly faster than gcc. > > I think the URL you want is actually >

Hi, I've attached 2 .ll files which are supposed to be equivalent but 'unopt-fail.ll' causes a crash in webkit's test suite while 'unopt-pass.ll' does not. I can't give more details about the crash, when I run the crashing test it in isolation it passes, when I run the full suite it crashes; it boggles the mind. Below I provide the optimized asm that is produced from