Right, as you did for other cases. It works here as well.
Thanks,
Igor
On Wed, Jun 19, 2013 at 11:05 AM, Jakub Jelinek wrote:
> On Wed, Jun 19, 2013 at 11:01:59AM +0400, Igor Zamyatin wrote:
>> The change also affects vectorizer in avx case which could be seen for
>> gcc.dg/tre
The change also affects vectorizer in avx case which could be seen for
gcc.dg/tree-ssa/loop-19.c test.
After the change report says
loop-19_bad.c:16: note: === vect_analyze_data_refs_alignment ===
loop-19_bad.c:16: note: vect_compute_data_ref_alignment:
loop-19_bad.c:16: note: can't force alignme
Ping?
On Mon, Jun 10, 2013 at 2:13 PM, Igor Zamyatin wrote:
> Hi!
>
> This patch mentions support of Silvermont architecture in the
> gcc-4.9/changes.html page.
>
> OK to install?
>
> Thanks,
> Igor
>
> I
Please see updated patch.
Is it ok to install?
Thanks,
Igor
Changelog:
2013-06-11 Igor Zamyatin
* doc/invoke.texi (core-avx2): Document.
(slm): Likewise.
(atom): Updated with MOVBE.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index b7b32f7..dd82880
Hi!
Following patch documents Intel Silvermont support.
OK to install?
Thanks,
Igor
Changelog:
2013-06-10 Igor Zamyatin
* doc/invoke.texi: Document slm.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index b7b32f7..e4f1d45 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc
Hi!
This patch mentions support of Silvermont architecture in the
gcc-4.9/changes.html page.
OK to install?
Thanks,
Igor
Index: htdocs/gcc-4.9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v
retrieving re
Like this?
On Fri, May 31, 2013 at 3:45 PM, Uros Bizjak wrote:
> On Fri, May 31, 2013 at 1:38 PM, Igor Zamyatin wrote:
>> We do want to use the same register for float_extend.
>
> OK then. Please add a comment for this fact and also, please put
> single-line preparation statem
op of the list have the same priority we consider instruction
>> which producer(s) were scheduled earlier as the best candidate.
>>
>> Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk?
>>
>> 2013-05-30 Yuri Rumyantsev
>>
These changes are what we used to try here at Intel after bunch of
changes which made pre-alloc scheduler more stable. We benchmarked
both register pressure algorithms and overall result was not that
promising.
We saw number of regressions e.g. for optset "-mavx -O3 -funroll-loops
-ffast-math -mar
Hi!
This small change enables FP reassociation for AVX2 processors. This
gives ~+1.5% in performance geomean for spec2006FP tests.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2013-02-14 Igor Zamyatin
* config/i386/i386.c (initial_ix86_tune_features): Turn on fp
Gerald,
Thanks a lot for your remarks!
Below is updated patch which will be checked in.
Thanks,
Igor
On Mon, Feb 18, 2013 at 3:07 AM, Gerald Pfeifer wrote:
> On Fri, 15 Feb 2013, Igor Zamyatin wrote:
>> Is it ok for wwwdocs?
>
> Index: htdocs/gcc-4
Gerald,
Is it ok for wwwdocs?
Thanks,
Igor
On Wed, Feb 13, 2013 at 3:21 PM, Uros Bizjak wrote:
> On Wed, Feb 13, 2013 at 12:17 PM, Igor Zamyatin wrote:
>>>
>>> Please also mention new -mfxsr, -mxsave and -mxsaveopt options.
>>>
>>>>New buil
>
> Please also mention new -mfxsr, -mxsave and -mxsaveopt options.
>
>>New built-in functions to detect run-time CPU type and ISA:
>>
>> A built-in function __builtin_cpu_is has been added
>> to
>> ***
>> *** 524,529
>> --- 530,538
>> http://gcc.
Hi,
This patch updates GCC 4.8 changes.html to mention Broadwell's
features, RTM and HLE support and fixed pre-reload scheduler.
OK to commit?
Thanks,
Igor
Index: htdocs/gcc-4.8/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/g
We also plan to test these changes along with LRA
On Sun, Sep 30, 2012 at 4:33 PM, Uros Bizjak wrote:
> On Tue, Sep 18, 2012 at 1:31 PM, Uros Bizjak wrote:
>
>>> This patch aims to fix all stability issues related to using the first
>>> scheduler in gcc
>>> for x86 target (there several reported
Andorid. Ok to commit?
Thanks,
Igor
Changelog:
gcc/testsuite
2012-09-24 Igor Zamyatin
Test changes for case when long double size is equal double size
* gcc.target/i386/20030217-1.c: Added check for
large_long_double effective target.
* gcc.target/i386/387-3.c
On Tue, Aug 28, 2012 at 1:34 PM, Uros Bizjak wrote:
> On Tue, Aug 28, 2012 at 11:24 AM, Igor Zamyatin wrote:
>
>> I'd like this patch (original version at the bottom) also to be
>> backported into 4.7.
>>
>> Is it safe to backport?
>
> Looks safe to me.
&
Hi!
I'd like this patch (original version at the bottom) also to be
backported into 4.7.
Is it safe to backport?
On Fri, Aug 24, 2012 at 11:35 AM, Uros Bizjak wrote:
> On Fri, Aug 24, 2012 at 9:22 AM, Igor Zamyatin wrote:
>
>> Following change enables look ahead feature in t
Hi!
Following change enables look ahead feature in the code scheduler for
Atom processors. This gives quite reasonable gain for some benchmarks
for mobile market.
Overall compile time increase for SPEC2000 is about 1%.
Regtested for x86_64 and also bootstrapped with "--with-arch=core2
--with-cpu
Hi all!
Patch aims to fix instability introduced by first scheduler on x86. In
particular it targets following list:
[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46843
[2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46829
[3] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36680
[4] http://gcc.gnu
(stack_protect_test_): Likewise.
* gcc/defaults.h: Define macro TARGET_HAS_BIONIC to 0 - target does
not have Bionic by default
* config/linux.h: Redefine macro TARGET_HAS_BIONIC to (OPTION_BIONIC)
Macro OPTION_BIONIC is defined in this file and provide
/07/2012, at 10:08 PM, Uros Bizjak wrote:
>
>> On Mon, Jul 23, 2012 at 10:00 PM, Igor Zamyatin wrote:
>>
>>> 2012-07-23 Sergey Melnikov
>>>
>>>* config/i386/i386.md (stack_protect_set): Disable the pattern
>>>for Android since And
Hi!
Since this change for stack-protector enabling hurts mingw compiler
(see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53980 and
http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00638.html) we'd like to
make change more general.
Please see new patch in attachment.
Tested in android environment(x86_6
On x86_64 the same happens. Also I modified list of failing tests -
now it is correct
On Fri, Jul 20, 2012 at 11:43 AM, Igor Zamyatin wrote:
>>
>> Tobias Burnus wrote:
>>> I will now regtest everything, read through the whole patch - your
>>> part and mine, upda
>
> Tobias Burnus wrote:
>> I will now regtest everything, read through the whole patch - your
>> part and mine, update the ChangeLog and commit it tomorrow.
>
> I have now committed the attached version as Rev. 189700!
>
> Thanks agai for the review!
>
> Tobias
>
This seems to cause following fai
7,7 @@
(match_operand:P 2 "memory_operand" "m")]
UNSPEC_SP_TEST))
(clobber (match_scratch:P 3 "=&r"))]
- ""
+ "!(flag_android && OPTION_BIONIC)"
"mov{}\t{%1, %3|%3, %1}\;xor{}\t{%2, %
Right, flag_android looks better, thanks.
Probably it's even better to check also bionic (OPTION_BIONIC)
On Fri, Jul 6, 2012 at 12:13 PM, Andrew Pinski wrote:
> On Fri, Jul 6, 2012 at 12:49 AM, Igor Zamyatin wrote:
>> Hi!
>>
>> For runtime stack protector enabling on
Hi!
For runtime stack protector enabling on x86 for Android we have to
disable current glibc-based implementation and turn on default one
since bionic doesn't use value from gs:0x14.
Tested in android environment(x86_64-*-linux-android), also
bootstrapped and regtested on x86_64-unknown-linux-gnu
On Wed, Jun 27, 2012 at 9:14 PM, Richard Henderson wrote:
> On 06/27/2012 10:08 AM, Igor Zamyatin wrote:
>> On Wed, Jun 27, 2012 at 9:00 PM, Richard Henderson wrote:
>>> > On 06/27/2012 09:07 AM, Igor Zamyatin wrote:
>>>> >> May I ask about the purpose of
On Wed, Jun 27, 2012 at 9:00 PM, Richard Henderson wrote:
> On 06/27/2012 09:07 AM, Igor Zamyatin wrote:
>> May I ask about the purpose of the following piece of change? Doesn't
>> it affect non-sse cases either?
>
> Err, no, it doesn't affect non-sse cases. All
May I ask about the purpose of the following piece of change? Doesn't
it affect non-sse cases either?
@@ -32038,7 +32042,15 @@ ix86_rtx_costs (rtx x, int code, int
outer_code_i, int opno, int *total,
case ASHIFTRT:
case LSHIFTRT:
case ROTATERT:
- if (!TARGET_64BIT && GET_MODE (XEX
Hi, Uros!
Sorry, I didn't realize that patch was missed. I attached new version.
Changelog:
2012-05-29 Yuri Rumyantsev
* config/i386/i386.c (x86_sched_reorder): New function.
Added new function x86_sched_reorder.
As for multiply modes, currently we handled most frequent case f
Ping?
On Sun, May 6, 2012 at 11:27 AM, Igor Zamyatin wrote:
> Ping. Could x86 maintainer(s) look at these changes?
>
> Thanks,
> Igor
>
> On Fri, Apr 20, 2012 at 4:04 PM, Igor Zamyatin wrote:
>> On Tue, Apr 17, 2012 at 12:27 AM, Igor Zamyatin wrote:
>>> On Fri
Ping?
On Sat, May 12, 2012 at 1:26 AM, Igor Zamyatin wrote:
> Ping?
>
> On Fri, Apr 27, 2012 at 4:42 PM, Igor Zamyatin wrote:
>> On Wed, Apr 25, 2012 at 6:41 PM, Richard Guenther
>> wrote:
>>> On Wed, Apr 25, 2012 at 4:32 PM, Igor Zamyatin wrote:
>>>>
Ping?
On Fri, Apr 27, 2012 at 4:42 PM, Igor Zamyatin wrote:
> On Wed, Apr 25, 2012 at 6:41 PM, Richard Guenther
> wrote:
>> On Wed, Apr 25, 2012 at 4:32 PM, Igor Zamyatin wrote:
>>> On Wed, Apr 25, 2012 at 1:14 PM, Richard Guenther
>>> wrote:
>>>&
at 10:08 PM, H.J. Lu wrote:
> On Mon, May 7, 2012 at 11:04 AM, Maxim Kuvyrkov
> wrote:
>> On 6/05/2012, at 7:02 PM, Igor Zamyatin wrote:
>>
>>> Hi!
>>>
>>> The patch enables stack protector for Android.
>>> Android targets don't conta
Ping. Could x86 maintainer(s) look at these changes?
Thanks,
Igor
On Fri, Apr 20, 2012 at 4:04 PM, Igor Zamyatin wrote:
> On Tue, Apr 17, 2012 at 12:27 AM, Igor Zamyatin wrote:
>> On Fri, Apr 13, 2012 at 4:20 PM, Andrey Belevantsev wrote:
>>> On 13.04.2012 14:18, I
Hi!
The patch enables stack protector for Android.
Android targets don't contain necessary information in features.h so
we explicitly enable stack protector for Android.
Bootstrapped and regtested on x86_64. Ok to commit?
Thanks,
Igor
2012-05-06 Igor Zamyatin
* configure.ac:
On Wed, Apr 25, 2012 at 6:41 PM, Richard Guenther
wrote:
> On Wed, Apr 25, 2012 at 4:32 PM, Igor Zamyatin wrote:
>> On Wed, Apr 25, 2012 at 1:14 PM, Richard Guenther
>> wrote:
>>> On Wed, Apr 25, 2012 at 10:56 AM, Igor Zamyatin wrote:
>>>> Hi all!
>&
Are you sure that tree-level unrollers are turned on at O2? My
impression was that they work only at O3 or with f[unroll,peel]-loops
flags.
On Tue, Apr 24, 2012 at 6:13 PM, Andi Kleen wrote:
> tejohn...@google.com (Teresa Johnson) writes:
>
>> This patch adds heuristics to limit unrolling in loop
On Wed, Apr 25, 2012 at 1:14 PM, Richard Guenther
wrote:
> On Wed, Apr 25, 2012 at 10:56 AM, Igor Zamyatin wrote:
>> Hi all!
>>
>> I'd like to post for review the patch which makes some costs adjusting
>> in get_computation_cost_at routine in ivopts part.
>&g
Hi all!
I'd like to post for review the patch which makes some costs adjusting
in get_computation_cost_at routine in ivopts part.
As mentioned in the PR changes also fix the bwaves regression from PR 52272.
Also changes introduce no degradations on spec2000/2006 and
EEMBC1.1/2.0(this was measured
This testcase is reported as failed on x86
>
> Noticed that this testcase wasn't put in as part of the patch. Fixed as
> follows.
>
> tested x86/linux
>
> -benjamin
>
On Tue, Apr 17, 2012 at 12:27 AM, Igor Zamyatin wrote:
> On Fri, Apr 13, 2012 at 4:20 PM, Andrey Belevantsev wrote:
>> On 13.04.2012 14:18, Igor Zamyatin wrote:
>>>
>>> On Thu, Apr 12, 2012 at 5:01 PM, Andrey Belevantsev
>>> wrote:
>>>>
On Thu, Apr 12, 2012 at 3:16 PM, Richard Guenther
wrote:
> On Thu, Apr 12, 2012 at 1:05 PM, Igor Zamyatin wrote:
>> On Wed, Apr 11, 2012 at 12:39 PM, Richard Guenther
>> wrote:
>>> On Tue, Apr 10, 2012 at 8:43 PM, Igor Zamyatin wrote:
>>>> Hi All!
>>&
On Fri, Apr 13, 2012 at 4:20 PM, Andrey Belevantsev wrote:
> On 13.04.2012 14:18, Igor Zamyatin wrote:
>>
>> On Thu, Apr 12, 2012 at 5:01 PM, Andrey Belevantsev
>> wrote:
>>>
>>> On 12.04.2012 16:38, Richard Guenther wrote:
>>>>
>&
On Fri, Apr 13, 2012 at 2:18 PM, Igor Zamyatin wrote:
> On Thu, Apr 12, 2012 at 5:01 PM, Andrey Belevantsev wrote:
>> On 12.04.2012 16:38, Richard Guenther wrote:
>>>
>>> On Thu, Apr 12, 2012 at 2:36 PM, Igor Zamyatin
>>> wrote:
>>>>
>&g
On Thu, Apr 12, 2012 at 5:01 PM, Andrey Belevantsev wrote:
> On 12.04.2012 16:38, Richard Guenther wrote:
>>
>> On Thu, Apr 12, 2012 at 2:36 PM, Igor Zamyatin
>> wrote:
>>>
>>> On Thu, Apr 12, 2012 at 4:24 PM, Richard Guenther
>>> wrote:
>
On Thu, Apr 12, 2012 at 4:24 PM, Richard Guenther
wrote:
> On Thu, Apr 12, 2012 at 2:00 PM, Alexander Monakov wrote:
>>
>>> Can atom execute two IMUL in parallel? Or what exactly is the pipeline
>>> behavior?
>>
>> As I understand from Intel's optimization reference manual, the behavior is
>> a
On Wed, Apr 11, 2012 at 12:39 PM, Richard Guenther
wrote:
> On Tue, Apr 10, 2012 at 8:43 PM, Igor Zamyatin wrote:
>> Hi All!
>>
>> Here is a patch that enables unroll at O2 for Atom.
>>
>> This gives good performance boost on EEMBC 2.0 (~+8% in Geomean for 32
On Wed, Apr 11, 2012 at 5:34 PM, Andi Kleen wrote:
> Richard Guenther writes:
>>
>> 5% is not moderate. Your patch does enable unrolling at -O2 but not -O3,
>> why? Why do you disable register renaming? check_imull requires a function
>> comment.
>>
>> This completely looks like a hack for EEMB
On Wed, Apr 11, 2012 at 6:10 PM, Richard Guenther
wrote:
> On Wed, Apr 11, 2012 at 3:38 PM, Andi Kleen wrote:
>> Igor Zamyatin writes:
>>
>>> Hi All!
>>>
>>> It is known that imul placement is rather critical for Atom processors
>>>
On Wed, Apr 11, 2012 at 5:38 PM, Andi Kleen wrote:
> Igor Zamyatin writes:
>
>> Hi All!
>>
>> It is known that imul placement is rather critical for Atom processors
>> and changes try to improve imul scheduling for Atom.
>>
>> This gives +5% performance
Hi All!
It is known that imul placement is rather critical for Atom processors
and changes try to improve imul scheduling for Atom.
This gives +5% performance on several tests from new OA 2.0 testsuite
from EEMBC.
Tested for i386 and x86-64, ok for trunk?
ChangeLog:
2012-04-10 Yuri Rumyantse
Hi All!
Here is a patch that enables unroll at O2 for Atom.
This gives good performance boost on EEMBC 2.0 (~+8% in Geomean for 32
bits) with quite moderate code size increase (~5% for EEMBC2.0, 32
bits).
Tested for i386 and x86-64, ok for trunk?
Thanks,
Igor
ChangeLog:
2012-04-10 Yakovlev V
Unfortunately patch doesn't help neither for separate EEMBC_2_0 tests
nor for the whole benchmark.
Do you want me to do some debugging here?
On Fri, Jan 20, 2012 at 10:13 PM, Vladimir Makarov wrote:
> On 01/19/2012 03:52 PM, Vladimir Makarov wrote:
>>
>> On 01/18/2012 02:30 PM, Zamyatin, Igor wr
Thanks, I'll look into your remarks
On Thu, Dec 29, 2011 at 5:33 PM, Ira Rosen wrote:
>
>
> Igor Zamyatin wrote on 29/12/2011 02:29:46 PM:
>
>>
>> Because it includes AVX and AVX2 which deals with int and for AVX2
>> there are no problems with doubled diagnos
wrote:
>
>
> Igor Zamyatin wrote on 29/12/2011 02:04:45 PM:
>
>> When compiler configured with, say corei7-avx, it outputs twice more
>> diagnostics on integer tests since AVX deals mostly with floats. I.e.
>> compiler tries to vectorize on AVX vector size, than fails and t
t; Could you please explain what are you trying to do? How is
>> +# Return 1 if the target supports hardware vectors of float and doesn't
> support
>> +# vectors of int, 0 otherwise.
> related to the number of times that pattern is detected?
>
> Thanks,
> Ira
>
&g
Ilya is on vacation so I'll make the answer.
Overall score became worse on 0.3%.
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On
> Behalf Of Vladimir Makarov
> Sent: Thursday, December 22, 2011 8:15 PM
> To: Ilya Enkovich
> Cc: gcc-pat
Hi,
Here is another patch about failures in gcc.dg/vect tests. These
changes fix fails that could be seen on avx-built compilers. It also
introduces no FAILs/XFAILs/XPASSes/ERRORs on regular i686, x86_64,
avx2_32, avx2_64.
Is it ok for the trunk?
Thanks,
Igor
2011-12-28 Igor Zamyatin
61 matches
Mail list logo
