search for: 112805

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 make my vector-intensive code two times slower so it would > be much appreciated to revert these changes for the 2.8 release. > Hi Nic...

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

...to me and I'll fix it in TOT next week! Thanks for narrowing it down! On Wednesday, September 22, 2010, Nicolas Capens <nicolas.capens at gmail.com> wrote: > Hi all, > > I think I figured it out: > 112804 causes 64-bit UNPCKLBW to no longer be selected for certain cases. > 112805 is benign. > 112806 causes 64-bit UNPCKHBW to no longer be selected for certain cases. > > I've attached a potential fix for 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. I...

...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 they make my vector-intensive code two times slower so it would >>>> be much appreciated to revert these chang...

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 they make my vector-intensive code two times slower so it would > be much appreciated to revert these changes for the 2.8 release. > > T...

...ev] LLVM 2.8 and MMX > > > 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 they make my vector-intensive code two times slower so it would >> be much appreciated to revert these changes for the 2.8 release....

...> 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 they make my vector-intensive code two times slower so it would >>> be much appreciated to revert these changes for the 2...

...mdev at cs.uiuc.edu Subject: Re: [LLVMdev] LLVM 2.8 and MMX 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 they make my vector-intensive code two times slower so it would > be much appreciated to revert these changes for the 2.8 release. > > T...

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