similar to: [LLVMdev] LLVM 2.8 and MMX

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

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

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 Kleckner wrote: > This thread confuses me. I thought

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 21, 2010, at 10:23 AMPDT, Nicolas Capens wrote: > Hi all, > > Sorry for the late reply. I got sidetracked by other fun projects. ;-) > > I found that the performance regression is caused by revisions 112804, > 112805 and 112806. Those changes were made 2 days prior to the 2.8 > branching, so it may have not been the intention to include them there? > Either way

On Sep 21, 2010, at 10:23 AM, Nicolas Capens wrote: > Hi all, > > Sorry for the late reply. I got sidetracked by other fun projects. ;-) > > I found that the performance regression is caused by revisions 112804, > 112805 and 112806. Those changes were made 2 days prior to the 2.8 > branching, so it may have not been the intention to include them there? > Either way they

Hi Dale, I suspect that these patches were intended to improve 128-bit vector performance but caused certain 64-bit vector operations to no longer lower to MMX instructions. Anyway, now that I've narrowed it down to these patches I think I can narrow it down further to a specific case so I can file a bug... Will Bruno be back soon or is he no longer working on the project for good? Cheers,

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

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 Dale, I will not change the default. I would dislike to see any regressions due to this type of change. -- Mon Ping On Nov 20, 2008, at 10:12 AM, Dale Johannesen wrote: > > On Nov 19, 2008, at 11:57 PMPST, Mon Ping Wang wrote: > >> Hi, >> >> When setting -mattr option on X86, I would like to treat MMX >> separately from SSE levels. This would allow a

On 31-Jul-08, at 2:38 PM, Dan Gohman wrote: > On Jul 31, 2008, at 7:22 AM, Nicolas Capens wrote: >> In the same breath I’d also like to kindly ask if someone could have >> a look at the reverse operations, namely trunk from 128 to 64 bit >> using movdq2q, and 128 to 32 and 64 to 32 using movd. This also >> seems related to Bug 2585. Thanks again. > > The operations

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 all, How do I generate the movq2dq SSE2 instruction using the IRBuilder? There is no zext from 64-bit to 128-bit (corresponding to MMX to XMM register transfer) as far as I can tell. So I've tried inserting an i64 into a v2i64, which generates valid code but rather a number of stores and loads on the stack instead of a single movq2dq. Looking though the code, I found a pattern for

Hi all, Recently some great work has been done to implement vector shifts as described in the language reference, and I'd like to contribute by attempting to match these operations on x86 to MMX and SSE instructions whenever possible. I'm experienced in writing MMX and SSE assembly but I'm unfamiliar with how LLVM performs instruction selection. So every bit of information to

On Jul 31, 2008, at 7:22 AM, Nicolas Capens wrote: > In the same breath I’d also like to kindly ask if someone could have > a look at the reverse operations, namely trunk from 128 to 64 bit > using movdq2q, and 128 to 32 and 64 to 32 using movd. This also > seems related to Bug 2585. Thanks again. The operations you're describing can be represented as insertelement and

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 them weren't introduced until SSE or SSSE3, and require

Hi Stefanus, I'm not if using MMX instructions when doing operations on 64-bit vectors is so terrible? With x86-64 you have double the registers, but it comes at the cost of longer instruction encodings. So there's probably no benefit using SSE. Or am I missing something? Cheers, Nicolas -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at