This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Generic tuning in x86-tune.def 1/2
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 2 Oct 2013 17:20:47 -0700
- Subject: Re: Generic tuning in x86-tune.def 1/2
- Authentication-results: sourceware.org; auth=none
- References: <20130927085640 dot GD21484 at kam dot mff dot cuni dot cz> <CAMe9rOqQG1Lyb0aNKe2ShZ-_0Ong0cejPj=JBLv=vNyJSbO46Q at mail dot gmail dot com> <20130927153622 dot GA11251 at kam dot mff dot cuni dot cz> <CAMe9rOqQpKn+sW1_Ck0g1CwNX-uTU2kXbt4CSOfwW66Z39ZZMg at mail dot gmail dot com>
On Fri, Sep 27, 2013 at 8:46 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> So I would incline to be apply extra care on this flag and keep it for extra
>> release or two. Most of gcc.opensuse.org testing runs on these and adding
>> random branch mispredictions will trash them.
>>
>> At the related note, would would you think of X86_TUNE_PARTIAL_FLAG_REG_STALL?
>> I benchmarked it on my I5 notebook and it seems to have no measurable effects
>> on spec2k6.
>>
>> I also did some benchmarking of the patch to disable alignments you proposed.
>> Unforutnately I can measure slowdowns on fam10/bdver/and on botan/hand written
>> loops even for core.
>
> I am not surprised about hand written loops. Have you
> tried SPEC CPU rate?
>
>> I am considering to drop the branch target/function alignment and keep only loop
>> alignment, but I did not test this yet.
>>
This sounds a good idea. I will give it a try on Intel processors.
--
H.J.