> Thanks,
Note that there is no "i386" component in Bugzilla, only a "target" so this
should have been PR target/49089. The end result is that there are no xrefs in
the PR, which is still open btw. So please add the xrefs to the commits in the
PR manually and close it if you are done with it.
: [PATCH, PR 49089] Don't split AVX256 unaligned loads by default on
bdver1 and generic
On Mon, Jun 20, 2011 at 8:03 PM, Fang, Changpeng wrote:
> I modified the patch as H.J. suggested (patch attached).
>
> Is it OK to commit to trunk now?
Yes, this is OK for trunk.
Thanks,
Uros.
On Mon, Jun 20, 2011 at 8:03 PM, Fang, Changpeng wrote:
> I modified the patch as H.J. suggested (patch attached).
>
> Is it OK to commit to trunk now?
Yes, this is OK for trunk.
Thanks,
Uros.
Subject: Re: [PATCH, PR 49089] Don't split AVX256 unaligned loads by default on
bdver1 and generic
On Fri, Jun 17, 2011 at 3:18 PM, Fang, Changpeng wrote:
> Hi,
>
> I added AVX256_SPLIT_UNALIGNED_STORE to ix86_tune_indices
> and put m_COREI7, m_BDVER1 and m_GENERIC as the targ
On Fri, Jun 17, 2011 at 3:18 PM, Fang, Changpeng wrote:
> Hi,
>
> I added AVX256_SPLIT_UNALIGNED_STORE to ix86_tune_indices
> and put m_COREI7, m_BDVER1 and m_GENERIC as the targets that
> enable it.
>
> Is this OK?
Can you do something similar to how MASK_ACCUMULATE_OUTGOING_ARGS
is handled?
T
, Changpeng
Cc: Richard Guenther; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH, PR 49089] Don't split AVX256 unaligned loads by default on
bdver1 and generic
On Fri, Jun 17, 2011 at 10:45 AM, Fang, Changpeng
wrote:
>>Why not just move AVX256_SPLIT_UNALIGNED_STORE
>>and AVX256_SPLIT_
On Fri, Jun 17, 2011 at 10:45 AM, Fang, Changpeng
wrote:
>>Why not just move AVX256_SPLIT_UNALIGNED_STORE
>>and AVX256_SPLIT_UNALIGNED_LOAD to ix86_tune_indices?
>
> I would like to keep the -m option so that at least we can explicitly turn
> off the splittings when regressions are found!
I prefe
>Why not just move AVX256_SPLIT_UNALIGNED_STORE
>and AVX256_SPLIT_UNALIGNED_LOAD to ix86_tune_indices?
I would like to keep the -m option so that at least we can explicitly turn
off the splittings when regressions are found!
By the way, I can add an index for store splitting, if you want.
Thanks
On Thu, Jun 16, 2011 at 4:54 PM, Fang, Changpeng wrote:
> Hi,
>
> I modify the patch to disable unaligned load splitting only for bdver1 at
> this moment.
> Unaligned load splitting degrades CFP2006 by 1.3% in geomean for both
> -mtune=bdver1 and
> -mtune=generic on Bulldozer. However, we agree
Hi,
I modify the patch to disable unaligned load splitting only for bdver1 at this
moment.
Unaligned load splitting degrades CFP2006 by 1.3% in geomean for both
-mtune=bdver1 and
-mtune=generic on Bulldozer. However, we agree with H.J's suggestion to
determine
the optimal optimization sets fo
On Wed, Jun 15, 2011 at 11:06 PM, Fang, Changpeng
wrote:
>>I have no problems on -mtune=Bulldozer. But I object -mtune=generic
>>change and did suggest a different approach for -mtune=generic.
>
> Something must have been broken for the unaligned load splitting in generic
> mode.
>
> While we lo
>I have no problems on -mtune=Bulldozer. But I object -mtune=generic
>change and did suggest a different approach for -mtune=generic.
Something must have been broken for the unaligned load splitting in generic
mode.
While we lose 1.3% on CFP2006 in geomean by splitting unaligned loads for
-mtu
On Tue, Jun 14, 2011 at 4:59 PM, Fang, Changpeng wrote:
>
>
>>
>> So, is it OK to commit this patch to trunk, and H.J's original patch + this
>> to 4.6 branch?
>
>>I have no problems on -mtune=Bulldozer. But I object -mtune=generic
>>change and did suggest a different approach for -mtune=generic
>
> So, is it OK to commit this patch to trunk, and H.J's original patch + this
> to 4.6 branch?
>I have no problems on -mtune=Bulldozer. But I object -mtune=generic
>change and did suggest a different approach for -mtune=generic.
What's your suggested approach for -mtune=generic?
My underst
On Tue, Jun 14, 2011 at 4:01 PM, Fang, Changpeng wrote:
> A similar argument is for software prefetching, which we observed a ~2%
> benefit on greyhound (not that much
> for Bulldozer). We would also prefer turning on software prefetching at -O3
> for -mtune=generic.
Sure, we can put everything
...@gmail.com]
Sent: Tuesday, June 14, 2011 8:05 AM
To: Jakub Jelinek; sergos@gmail.com
Cc: Richard Guenther; Fang, Changpeng; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH, PR 49089] Don't split AVX256 unaligned loads by default on
bdver1 and generic
On Tue, Jun 14, 2011 at 3:16 AM, Jakub Jelinek
On Tue, Jun 14, 2011 at 3:41 PM, Fang, Changpeng wrote:
>>It probably should go to the 4.6 branch as well.
>
> H.J. Lu's original patch that splits unaligned load and store was checked in
> gcc 4.7
> trunk. We found that, splitting unaligned store is beneficial to bdver1,
> splitting unaligned
>It probably should go to the 4.6 branch as well.
H.J. Lu's original patch that splits unaligned load and store was checked in
gcc 4.7
trunk. We found that, splitting unaligned store is beneficial to bdver1,
splitting unaligned
load degrades cfp2006 by 1.3% in geomean on Bulldozer. As a result,
On Tue, Jun 14, 2011 at 3:16 AM, Jakub Jelinek wrote:
> On Tue, Jun 14, 2011 at 12:13:47PM +0200, Richard Guenther wrote:
>> On Tue, Jun 14, 2011 at 1:59 AM, Fang, Changpeng
>> wrote:
>> > The patch ( http://gcc.gnu.org/ml/gcc-patches/2011-02/txt00059.txt ) which
>> > introduces splitting avx25
On Tue, Jun 14, 2011 at 12:13:47PM +0200, Richard Guenther wrote:
> On Tue, Jun 14, 2011 at 1:59 AM, Fang, Changpeng
> wrote:
> > The patch ( http://gcc.gnu.org/ml/gcc-patches/2011-02/txt00059.txt ) which
> > introduces splitting avx256 unaligned loads.
> > However, we found that it causes signi
On Tue, Jun 14, 2011 at 1:59 AM, Fang, Changpeng wrote:
> Hi,
>
> The patch ( http://gcc.gnu.org/ml/gcc-patches/2011-02/txt00059.txt ) which
> introduces splitting avx256 unaligned loads.
> However, we found that it causes significant regressions for cpu2006 (
> http://gcc.gnu.org/bugzilla/show_
Hi,
The patch ( http://gcc.gnu.org/ml/gcc-patches/2011-02/txt00059.txt ) which
introduces splitting avx256 unaligned loads.
However, we found that it causes significant regressions for cpu2006 (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49089 ).
In this work, we introduce a tune option that
22 matches
Mail list logo
