search for: 112804

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

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

Assign the bug 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...

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

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

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

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

...man'; llvmdev 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....

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

I been running shorewall with out any problems for several months. But I''ve now run into a problem. Hopefully this will be enough information. I''m running shorewall version 1.4.8. On Fedora core 1. Coming into my location I have a T1. I have 5 internet routable IP''s. I''m currently using one as my default internet connection. My ISP''s router is