Hi Honza,
That should be fine unless vectorization is done using extract/insert
instructions.
Thanks,
Evgeny
On Wed, Oct 25, 2017 at 12:25 PM, Jan Hubicka wrote:
> Hi,
> my core tuning patch has caused regression gcc.target/i386/pr61403.c which I
> have
> missed in my testing. The testcase lo
PING.
On Fri, Jun 24, 2016 at 1:41 PM, Evgeny Stupachenko wrote:
> Hi,
>
> Fix ICE when IPA-cp and target_clones are applied to the same function.
> Is the patch ok for trunk?
>
> Thanks,
> Evgeny
>
> 2016-06-24 Evgeny Stupachenko
>
> gcc/
> * ipa
Hi,
Fix ICE when IPA-cp and target_clones are applied to the same function.
Is the patch ok for trunk?
Thanks,
Evgeny
2016-06-24 Evgeny Stupachenko
gcc/
* ipa-cp.c (determine_versionability): Do not create constprop clones,
when target_clones attribute is set.
diff --git a
Some tests in the patch already updated (ifunc require condition
added) by Uros commit: ac39b078992c27934ea53cb580dbd79f75b6c727
I'll ask to commit attached patch.
x86 bootstrap and make check passed.
2015-11-03 Evgeny Stupachenko
gcc/
* multiple_target.c (create_dispatcher_
Yes, that is exactly what should fix the tests.
Unfortunately I don't have access to darwin machine right now.
Can you please test if the patch (attached) fixes the tests?
gcc/
* multiple_target.c (create_dispatcher_calls): Add target check
on ifunc.
(create_target_clone):
I've fixed the misprint and vertical spaces.
I'll ask to commit the patch when x86 bootstrap and make check finished.
Thanks,
Evgeny
Updated ChangeLog:
2015-10-30 Evgeny Stupachenko
gcc/
* Makefile.in (OBJS): Add multiple_target.o.
* attrib.c (make_attribute):
On Thu, Oct 29, 2015 at 8:02 PM, Jan Hubicka wrote:
>> Yes. This is not necessary. However that way we'll have the following
>> code in dispatcher:
>> cmpl$6, __cpu_model+4(%rip)
>> sete%al
>> movzbl %al, %eax
>> testl %eax, %eax
>> jle .L16
>
On Mon, Oct 26, 2015 at 6:50 PM, Jeff Law wrote:
> On 10/12/2015 05:35 PM, Evgeny Stupachenko wrote:
>>
>> Hi All,
>>
>> Here is a new version of patch (attached).
>> Bootstrap and make check are in progress (all new tests passed).
>>
>> New tes
PING.
On Thu, Oct 15, 2015 at 12:32 AM, Evgeny Stupachenko wrote:
> Bootstrap and make check for x86 passed. No new fails.
> Please ignore an empty line added to omp-low.c in the patch, the
> misprint will be removed prior to a commit.
>
> Thanks,
> Evgeny
>
> On Tue,
Bootstrap and make check for x86 passed. No new fails.
Please ignore an empty line added to omp-low.c in the patch, the
misprint will be removed prior to a commit.
Thanks,
Evgeny
On Tue, Oct 13, 2015 at 2:35 AM, Evgeny Stupachenko wrote:
> Hi All,
>
> Here is a new version of patch
ute is
replaced by 2 corresponding "target" attributes.
I've filed PR67946 on this:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67946
Thanks,
Evgeny
ChangeLog:
2015-10-13 Evgeny Stupachenko
gcc/
* Makefile.in (OBJS): Add multiple_target.o.
* attrib.c (make_attrib
On Fri, Oct 9, 2015 at 11:04 PM, Jan Hubicka wrote:
>> On Fri, Oct 9, 2015 at 9:27 PM, Jan Hubicka wrote:
>> >> >Of course it also depends what you inline into function. You can have
>> >> >
>> >> >bar() target(-mavx) {fancy avx code}
>> >> >foobar() { .. if (avx) bar();}
>> >> >foo() ctarget
On Fri, Oct 9, 2015 at 9:27 PM, Jan Hubicka wrote:
>> >Of course it also depends what you inline into function. You can have
>> >
>> >bar() target(-mavx) {fancy avx code}
>> >foobar() { .. if (avx) bar();}
>> >foo() ctarget(-mavx,-mno-avx) {foobar();}
"no-" targets are not supported
On Thu, Oct 8, 2015 at 10:00 PM, Jeff Law wrote:
> On 09/24/2015 04:28 PM, Evgeny Stupachenko wrote:
>>
>> I've fixed ICE and review issues.
>> x86 make check and bootstrap passed.
>>
>> Thanks,
>> Evgeny
>>
>> ChangeLog
>>
>>
PING.
On Fri, Sep 25, 2015 at 1:28 AM, Evgeny Stupachenko wrote:
> I've fixed ICE and review issues.
> x86 make check and bootstrap passed.
>
> Thanks,
> Evgeny
>
> ChangeLog
>
> 2015-09-25 Evgeny Stupachenko
>
> gcc/
> *
I've fixed ICE and review issues.
x86 make check and bootstrap passed.
Thanks,
Evgeny
ChangeLog
2015-09-25 Evgeny Stupachenko
gcc/
* Makefile.in (OBJS): Add multiple_target.o.
* multiple_target.c (make_attribute): New.
(create_dispatcher_calls):
Thank you for the review.
The patch still works with gcc 5, but the fail reproduced on trunk
(looks like it appeared while patch was at review). I'll debug it and
fix.
As a workaround to test the feature...
Removing
"gimple_call_set_fndecl (call, idecl);" from multiple_target.c
should resolve the I
PING 2.
On Tue, Sep 8, 2015 at 2:27 PM, Evgeny Stupachenko wrote:
> Ping.
>
> On Thu, Aug 27, 2015 at 2:18 PM, Evgeny Stupachenko
> wrote:
>> Hi All,
>>
>> Based on RFC:
>> https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01322.html
>>
>&
Ping.
On Thu, Aug 27, 2015 at 2:18 PM, Evgeny Stupachenko wrote:
> Hi All,
>
> Based on RFC:
> https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01322.html
>
> The patch implement an extension to Function Multiversioning that
> allows to clone a function for multiple tar
.
Will create 3 clones of foo(). One optimized with -mavx, one optimized
with -march=slm, and one with default optimizations.
And will create ifunc resolver that calls appropriate clone (same as
in Function Multiversioning).
Bootstrap and make check for x86 passed.
Is it ok for trunk?
2015-08
On Mon, Aug 3, 2015 at 9:43 PM, Jeff Law wrote:
> On 07/30/2015 04:19 PM, Evgeny Stupachenko wrote:
>>
>> Hi All,
>>
>> The patch enables new attribute 'ctarget',
>> The attribute force compiler to create clones of a function with the
>> attrib
You can't apply both 'ctarget' and 'target' attributes to a function.
The patch uses same target specific methods to create dispatcher and
target clones.
On Fri, Jul 31, 2015 at 1:30 AM, Andrew Pinski wrote:
> On Thu, Jul 30, 2015 at 3:19 PM, Evgeny Stupachenko
&
Forget C++ tests.
On Fri, Jul 31, 2015 at 1:19 AM, Evgeny Stupachenko wrote:
> Hi All,
>
> The patch enables new attribute 'ctarget',
> The attribute force compiler to create clones of a function with the
> attribute.
>
> For example:
> __attribute__((ctarge
minimum (like
target x86-64). Is it better?
What do you think about attribute name? 'ctarget' is short but not
informative. Other variants are 'target_clones', 'targets'...
Below is ChangeLog. Attached patch passed make check on x86.
Thanks,
Evgeny
2015-07-31
GCC built with latest binutils and the patch give the following
performance improve:
spec2000INT +3% at "-O2 -m32", +1,5% at "-O2 -m64".
Some other benchmark scores at "-O2" were also improved up to 6%.
The patch is very efficient for PIE mode.
Thanks,
Evgeny
On Tue, May 5, 2015 at 6:30 PM, H.J
Hi HJ,
I've checked spec2000 performance.
Only few spec binaries differ. Anyway performance is unchanged.
Thanks,
Evgeny
On Thu, Apr 30, 2015 at 10:08 PM, H.J. Lu wrote:
> On Thu, Apr 30, 2015 at 12:01 PM, Uros Bizjak wrote:
>> Hello!
>>
>> Attached patch switches x86 to TARGET_SUPPORTS_WIDE_INT
, Jan 12, 2015 at 1:50 PM, Jakub Jelinek wrote:
> On Mon, Jan 12, 2015 at 01:36:05PM +0300, Evgeny Stupachenko wrote:
>> "frame_dummy" does not use EBX in allocation now as there are enough
>> other registers (that we don't need to save/restore). So if we d
ases (__EH_FRAME_BEGIN__, &object, tbase, dbase);
#else
if (__register_frame_info)
__register_frame_info (__EH_FRAME_BEGIN__, &object);
#endif /* CRT_GET_RFIB_DATA */
On Mon, Jan 5, 2015 at 11:50 PM, Jeff Law wrote:
> On 12/28/14 09:46, Evgeny Stupachenko wrote:
>&g
Missed path in ChangeLog:
2014-12-28 Evgeny Stupachenko
* config/i386/gnu-user.h (CRT_GET_RFIB_DATA): Remove EBX register usage.
* config/i386/sysv4.h (CRT_GET_RFIB_DATA): Ditto.
On Sun, Dec 28, 2014 at 7:46 PM, Evgeny Stupachenko wrote:
> Hi,
>
> The patch removes
Hi,
The patch removes EBX usage from asm code used in libgcc/crtstuff.c
It is safe now, but potentially buggy when glibc is rebuild with GCC
5.0 as EBX is not GOT register any more.
x86 bootstrap, make check passed.
Is it ok?
Evgeny
2014-12-28 Evgeny Stupachenko
* gnu-user.h
On Wed, Dec 10, 2014 at 12:54 AM, Jakub Jelinek wrote:
> On Wed, Dec 10, 2014 at 12:33:52AM +0300, Evgeny Stupachenko wrote:
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/i386/blend.c
>> @@ -0,0 +1,61 @@
>> +/* Test correctness of size 3 store groups permutat
I've added the reproducer to the patch.
is it ok?
ChangeLog:
2014-12-10 Evgeny Stupachenko
gcc/testsuite
* gcc.target/i386/blend.c: New.
gcc/
* config/i386/i386.c (expand_vec_perm_pblendv): Gen new rtx for
expand_vec_perm_1 target.
diff --git a/gcc/config/i386
wrote:
> On 12/09/2014 07:59 AM, Evgeny Stupachenko wrote:
>> However patch is fixing spec2006 benchmark. Shouldn't that be enough
>> for regression testing?
>>
>
> No. Spec is not free.
>
>
> r~
I've tried to get smaller reproducer, however currently it is
complicated as several functions in GCC.
However patch is fixing spec2006 benchmark. Shouldn't that be enough
for regression testing?
Thanks,
Evgeny
On Tue, Dec 9, 2014 at 4:29 PM, Evgeny Stupachenko wrote:
> The ca
;>
>>> Is it ok?
>>
>> Please add a testcase.
>
> Also, it surprises me that we enter expand_vec_perm_pblendv with
> uninitialized (?) target. Does your patch only papers over a real
> problem up the call chain (hard to say without a testcase)?
>
> Uros.
>
&g
-funroll-loops
-flto -march=corei7.
Bootstrap and make check passed.
Is it ok?
Evgeny
2014-12-09 Evgeny Stupachenko
gcc/
* config/i386/i386.c (expand_vec_perm_pblendv): Gen new rtx for
expand_vec_perm_1 target.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
check passed.
Is it ok?
2014-11-28 Evgeny Stupachenko
gcc/testsuite
* gcc.target/i386/pr52252-atom-1.c: Delete.
gcc/
* tree-vect-data-refs.c (vect_transform_grouped_load): Limit shift
permutations to loads group of size 3.
diff --git a/gcc/testsuite/gcc.target/i386/pr52252
Hi,
Please note that currently the test:
int a[N];
short b[N*2];
for (int i = 0; i < N; ++i)
a[i] = b[i*2];
Is compiled to (with -march=corei7 -O2 -ftree-vectorize):
movdqa b(%rax), %xmm0
movdqa b-16(%rax), %xmm2
pand%xmm1, %xmm0
pand%xmm1, %xmm2
PING.
"200" currently looks optimal for x86.
Let's commit the following:
2014-11-21 Evgeny Stupachenko
* config/i386/i386.c (ix86_option_override_internal): Increase
PARAM_MAX_COMPLETELY_PEELED_INSNS.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.
Bootstrap / make check passed with updated patch.
Is it still ok?
It looks like we don't need "expand_vec_perm_vpshufb2_vpermq_even_odd"
any more with the patch.
However the clean up will be in the separate patch after appropriate testing.
Modified ChangeLog:
2014-11-20 Evg
ptions "-O2 -ftree-vectorize -msse2" } */
+
+void
+foo (unsigned char *a, unsigned char *b, unsigned char *c, int size)
+{
+ int i;
+
+ for (i = 0; i < size; i++)
+a[i] = (unsigned char) ((unsigned int)1 + b[i] * c[i] * 117);
+}
+
+/* { dg-final { scan-assembler "packuswb|vpunpck"
; i < size; i++)
+a[i] = (unsigned char) ((unsigned int)1 + b[i] * c[i] * 117);
+}
+
+/* { dg-final { scan-assembler "packuswb|vpunpck" } } */
On Thu, Nov 20, 2014 at 3:26 PM, Uros Bizjak wrote:
> On Thu, Nov 20, 2014 at 12:36 PM, Evgeny Stupachenko
> wrote:
>> Hi,
for trunk?
Evgeny
2014-11-20 Evgeny Stupachenko
gcc/testsuite
PR target/60451
* gcc.target/i386/pr60451.c: New.
gcc/
PR target/60451
* config/i386/i386.c (expand_vec_perm_even_odd_pack): New.
(expand_vec_perm_even_odd_1): Add new expand for SSE cases,
Code size for spec2000 is almost unchanged (many benchmarks have the
same binaries).
For those that are changed we have the following numbers (200 vs 100,
both dynamic build -Ofast -funroll-loops -flto):
183.equake +10%
164.gzip, 173.applu +3,5%
187.facerec, 191.fma3d +2,5%
200.sixstrack +2%
177.me
To avoid misunderstanding.
I haven't yet committed this obvious fix.
Is it ok?
On Wed, Nov 12, 2014 at 2:15 PM, Evgeny Stupachenko wrote:
> Committed r217359.
> However, it appeared that AVX2 uses vperm2i128 for the shift here
> (instead of palignr for SSSE3/AVX). To handle AVX2 c
rm2i128|palignr" } } */
On Tue, Nov 11, 2014 at 5:28 PM, Richard Biener
wrote:
> On Tue, Nov 11, 2014 at 3:21 PM, Evgeny Stupachenko
> wrote:
>> Hi,
>>
>> The patch extends shift permutations technique on power of 2 cases
>> (previously even/odd transformations was used
, but can confirm performance
gains only for x86.
On Fri, Nov 7, 2014 at 6:37 PM, Evgeny Stupachenko wrote:
> So are there any objections to enable this
> (PARAM_MAX_COMPLETELY_PEELED_INSNS increase from 100 to 120) for x86?
>
> On Fri, Oct 31, 2014 at 7:52 PM, Evgeny Stupachenko
>
quence for load group of length 4
from 31 to 20 insns.
Performance for the test in the patch improved by ~20%.
Bootstrap passed.
Make check in progress.
Is it ok?
2014-11-11 Evgeny Stupachenko
gcc/testsuite
* gcc.target/i386/pr52252-atom-1.c: New.
gcc/
* tree-vect-d
for PIC register.
(nonlocal_goto_receiver): Delete.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
On Fri, Nov 7, 2014 at 11:33 PM, H.J. Lu wrote:
> On Thu, Nov 6, 2014 at 5:01 AM, Evgeny Stupachenko wrote:
>> Now I see that equiv reload could be special
So are there any objections to enable this
(PARAM_MAX_COMPLETELY_PEELED_INSNS increase from 100 to 120) for x86?
On Fri, Oct 31, 2014 at 7:52 PM, Evgeny Stupachenko wrote:
> I've measured spec2000, spec2006 as well and EEMBC for Silvermont in addition.
> 100->120 change gives gain
Now I see that equiv reload could be special for PIC register. Let's
apply more conservative patch.
Darwin bootstrap passed with the patch applied on r216304 (along with
already committed to trunk patches from PR63618 and PR63620).
2014-11-06 Evgeny Stupachenko
PR target/
We don't emit extra SET_GOT. That is beneficial.
As for stack usage, that is RA to decide which register is more
beneficial to put on stack.
On Sat, Nov 1, 2014 at 8:33 PM, Mike Stump wrote:
> On Nov 1, 2014, at 5:39 AM, Evgeny Stupachenko wrote:
>> When PIC register is pseudo th
On Tue, Nov 4, 2014 at 1:40 AM, Jeff Law wrote:
> On 11/01/14 06:39, Evgeny Stupachenko wrote:
>>
>> When PIC register is pseudo there is nothing special about it's value
>> that setjmp can hurt. So if the pseudo register lives across
>> setjmp_receiver RA should c
like this.
The initial problem comes from non-local goto as it tries to emit
pseudo PIC register after reload.
On Fri, Oct 31, 2014 at 11:14 PM, Jeff Law wrote:
> On 10/17/14 08:08, Evgeny Stupachenko wrote:
>>
>> Hi,
>>
>> The patch fixes 1st fail in darwin bootsta
I've measured spec2000, spec2006 as well and EEMBC for Silvermont in addition.
100->120 change gives gain for Silvermont, the results on Haswell are flat.
On Fri, Oct 31, 2014 at 3:14 PM, Eric Botcazou wrote:
>> Agreed, I think the value of 100 was set decade ago by Zdenek and me
>> completely ar
PM, Evgeny Stupachenko
>> wrote:
>> > make check for gcc passed
>> >
>> > On Mon, Oct 27, 2014 at 11:10 AM, Evgeny Stupachenko
>> > wrote:
>> >> The results are the same for Silvermont.
>> >> There are no significant
The test passes now. So let's remove xfail.
2014-10-29 Evgeny Stupachenko
gcc/testsuite
* gcc.target/i386/pr23098.c: Remove xfail.
diff --git a/gcc/testsuite/gcc.target/i386/pr23098.c
b/gcc/testsuite/gcc.target/i386/pr23098.c
index 7f118dc..7f118bb 100644
--- a/gcc/test
Patch with the fixes:
Bootstrap, gcc make check and spec2000 with "-p" passed.
2014-10-29 Evgeny Stupachenko
gcc/testsuite
PR target/63534
* gcc.target/i386/mcount_pic.c: New.
gcc/
PR target/63534
* config/i386/i386.c (ix86_init_pic_reg): Emit
Agree. Let't stop at first insn after entry block notes.
As for the test it looks like mcount is general i?86 name.
Bootstrap and make check are in progress.
2014-10-28 Evgeny Stupachenko
gcc/testsuite
PR target/63534
* gcc.target/i386/mcount_pic.c: New.
gcc/
Thank you, Jakub.
The following patch passed bootstrap, gcc make check and spec2000 with
"-p -m32 -fPIC".
Is it ok?
ChangeLog:
2014-10-28 Evgeny Stupachenko
gcc/testsuite
* gcc.target/i386/mcount_pic.c: New.
gcc/
* config/i386/i386.c (ix86_init_pic_reg): Emit
make check for gcc passed
On Mon, Oct 27, 2014 at 11:10 AM, Evgeny Stupachenko wrote:
> The results are the same for Silvermont.
> There are no significant changes on Haswell.
> So I agree with Richard, let's enable this x86 wide.
>
> Bootstrap/ passed.
> Make check
The results are the same for Silvermont.
There are no significant changes on Haswell.
So I agree with Richard, let's enable this x86 wide.
Bootstrap/ passed.
Make check in progress.
Is it ok?
2014-10-25 Evgeny Stupachenko
* config/i386/i386.c (ix86_option_override_internal): Inc
What if we remove the check?
glibc build pass?
On Sat, Oct 25, 2014 at 3:09 AM, Andrew Pinski wrote:
> On Fri, Oct 10, 2014 at 12:43 AM, Evgeny Stupachenko
> wrote:
>> i386 specific part of the patch:
>>
>> 2014-10-08 Ilya Enkovich
>> Vladimir Mak
his looks just as a hack.
Isn't it similar to what was before but just adding additional "prints"?
On Fri, Oct 24, 2014 at 6:29 PM, Jakub Jelinek wrote:
> On Fri, Oct 24, 2014 at 06:12:15PM +0400, Evgeny Stupachenko wrote:
>> The following patch align stack for mcount a
if (!TARGET_64BIT_P (opts->x_ix86_isa_flags) && opts->x_flag_pic)
{
if (opts->x_flag_fentry > 0)
sorry ("-mfentry isn%'t supported for 32-bit in combination "
"with -fpic");
opts->x_flag_fentry = 0;
}
2014-10-24 Evgeny Stup
Linux x86 bootstrap/make check passed.
Darwin x86 bootstrap passed configured with "--with-cpu=intel"
"--with-cpu=corei7" issue refers to PR63620.
On Fri, Oct 17, 2014 at 6:08 PM, Evgeny Stupachenko wrote:
> Hi,
>
> The patch fixes 1st fail in darwin bootstarp.
>
>But here, after reload completes, there shouldn't be pseudos in the IL, so
>the condition should not trigger anymore.
At that point we'll just exit the condition earlier with !reload_completed.
On Thu, Oct 23, 2014 at 1:40 AM, Jakub Jelinek wrote:
> On Wed, Oct 22, 2014 at 03:34:38PM -0600, Jef
>What is ia32 specific on the test?
Just the fact the test fails on ia32 now, for 64 bit the test is very
simple, however we can test it as well.
Full patch with testcase:
2014-10-22 Evgeny Stupachenko
PR target/63534
PR target/63618
* cs
bling starting here:
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02186.html
On Fri, Oct 17, 2014 at 10:32 PM, Mike Stump wrote:
> On Oct 17, 2014, at 7:08 AM, Evgeny Stupachenko wrote:
>> The patch fixes 1st fail in darwin bootstarp.
>> When PIC register is pseudo we don't
There is a test for Linux x86 that also fails without the changes in the patch:
ChangeLog:
2014-10-22 Evgeny Stupachenko
PR rtl-optimization/63618
* gcc.target/i386/pr63618.c: New.
diff --git a/gcc/testsuite/gcc.target/i386/pr63618.c
b/gcc/testsuite/gcc.target/i386/pr63618.c
Yes, unconditionally.
If pic_reg is unused, RA will allocate a hard register for it and
treat it as free, DCE after reload will delete SET_GOT.
On Fri, Oct 17, 2014 at 6:20 PM, Jakub Jelinek wrote:
> On Fri, Oct 17, 2014 at 06:16:41PM +0400, Evgeny Stupachenko wrote:
>> Hi,
&
d by Jakub:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534#c8
There is opened bug on this: PR63527. However the fix of the bug is
more complicated.
Is it ok?
ChangeLog
2014-10-16 Evgeny Stupachenko
PR target/63534
* config/i386/i386.c (x86_function_profiler): Add GOT reg
Hi,
Some instructions (like one in PR63534) could have hidden use of PIC register.
Therefore we need to leave SET_GOT not deleted till reload completed.
The patch prevents SET_GOT from deleting while PIC register is pseudo.
Is it ok?
ChangeLog:
2014-10-17 Evgeny Stupachenko
PR
Hi,
The patch fixes 1st fail in darwin bootstarp.
When PIC register is pseudo we don't need to init it after setjmp or
non local goto.
Is it ok?
ChangeLog:
2014-10-17 Evgeny Stupachenko
PR target/63534
* config/i386/i386.c (builtin_setjmp_receiver): D
hangeLog
trunk/gcc/java/lang.c
On Wed, Oct 15, 2014 at 9:21 PM, Andrew Haley wrote:
> On 10/15/2014 06:12 PM, Evgeny Stupachenko wrote:
>> Updated ChangeLog:
>>
>> 2014-10-15 Evgeny Stupachenko
>>
>> PR target/63536
>> * lang.c (java_pr
Hi,
The patch fixes java i686 bootstrap for -mtune=intel/slm.
Recent changes triggered java to write a note on compilation for a
function without context.
make check in progress
Is it ok?
ChangeLog:
2014-10-15 Evgeny Stupachenko
PR target/63536
* java/lang.c
Hi,
Bootstaped with --enable-languages=c,c++,fortran,lto,go passed.
Make check in progress.
Is it ok?
ChangeLog
2014-10-14 Evgeny Stupachenko
* config/i386/i386.c (ix86_expand_split_stack_prologue): Make
__morestack calls local.
diff --git a/gcc/config/i386/i386.c b/gcc
Reattached.
On Mon, Oct 13, 2014 at 8:22 PM, Uros Bizjak wrote:
> On Mon, Oct 13, 2014 at 4:53 PM, Evgeny Stupachenko
> wrote:
>
>> ChangeLog for testsuite:
>>
>> 2014-10-13 Evgeny Stupachenko
>>
>> PR target/8340
>> PR middle-e
I don't see significant performance changes from the patch (with and
without patch enabling ebx) on x86 in 32bits mode.
Thanks,
Evgeny
On Sat, Oct 11, 2014 at 2:31 AM, Sebastian Pop wrote:
> Vladimir Makarov wrote:
>> I've tested and benchmarked the sub-pass on x86-64 and ARM. The
>> sub-pass
!= parts.index)
cost++;
On Fri, Oct 10, 2014 at 3:04 PM, Uros Bizjak wrote:
> On Fri, Oct 10, 2014 at 9:58 AM, Evgeny Stupachenko
> wrote:
>> the patch improves performance when previous are applied.
>> It makes RTL loop invariant behavior for GOT loads same as it w
\
+ : pic_offset_table_rtx \
+ ? INVALID_REGNUM \
+ : REAL_PIC_OFFSET_TABLE_REGNUM)
Is it ok?
On Fri, Oct 10, 2014 at 6:01 PM, Evgeny Stupachenko wrote:
> Updated ChangeLog:
> 2014-10-10 Ilya
On Fri, Oct 10, 2014 at 8:03 PM, Jeff Law wrote:
> On 10/10/14 01:42, Evgeny Stupachenko wrote:
>>
>> Hi,
>>
>> The patch enables EBX in RA for x86 32bits PIC mode.
>> It was discussed here:
>> https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02513.html
&g
I need to collect data from Haswell, but the patch should not help
it's performance much, just increase code size.
On Mon, Oct 13, 2014 at 12:01 PM, Richard Biener
wrote:
> On Fri, Oct 10, 2014 at 5:40 PM, Evgeny Stupachenko
> wrote:
>> Hi,
>>
Thanks. I've modified ChangeLog.
2014-10-10 Evgeny Stupachenko
* config/i386/x86-tune.def (X86_TUNE_SSE_PARTIAL_REG_DEPENDENCY):
Remove m_SILVERMONT and m_INTEL from the tune.
On Fri, Oct 10, 2014 at 7:58 PM, H.J. Lu wrote:
> On Fri, Oct 10, 2014 at 8:07 AM
Is it ok for trunk when pass bootstrap and make check?
Thanks,
Evgeny
2014-10-10 Evgeny Stupachenko
* config/i386/i386.c (ix86_option_override_internal): Increase
PARAM_MAX_COMPLETELY_PEELED_INSNS for CPUs with high branch cost.
* config/i386/i386.h (TARGET_HIGH_BRANCH_
make check.
Is it ok for trunk?
Thanks,
Evgeny
2014-10-10 Evgeny Stupachenko
* config/i386/x86-tune.def (X86_TUNE_PARTIAL_REG_DEPENDENCY):
Remove m_SILVERMONT and m_INTEL from the tune.
diff --git a/gcc/config/i386/x86-tune.def b/gcc/config/i386/x86-tune.def
index 215c63c..b6
e it only
+before reload_completed. */
On Fri, Oct 10, 2014 at 4:36 PM, Jakub Jelinek wrote:
> On Fri, Oct 10, 2014 at 02:34:07PM +0200, Rainer Orth wrote:
>> Uros Bizjak writes:
>>
>> > On Fri, Oct 10, 2014 at 9:43 AM, Evgeny Stupachenko
>> > wrote:
>
EBX.
In x86_address_cost the result of “REGNO (parts.base) >=
FIRST_PSEUDO_REGISTER” for hard ebx was always false. The patch makes
condition result
the same when parts.base is GOT register (the same for parts.index).
2014-10-08 Evgeny Stupachenko
* gcc/config/i386/i386.c (ix86_address_cost):
i386 specific part of the patch:
2014-10-08 Ilya Enkovich
Vladimir Makarov
* gcc/config/i386/i386.c (ix86_use_pseudo_pic_reg): New.
(ix86_init_pic_reg): New.
(ix86_select_alt_pic_regnum): Add check on pseudo register.
(ix86_save_reg): Likewise.
Hi,
The patch enables EBX in RA for x86 32bits PIC mode.
It was discussed here: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02513.html
Now there is working version with good performance and stability level
- it could be a solid first step of EBX enabling.
Bootstrap and make check passed.
There
}: ssse3_palignr_perm and AVX2
split: *avx_vperm_broadcast_.
On Wed, Oct 1, 2014 at 2:35 PM, Jakub Jelinek wrote:
> On Wed, Oct 01, 2014 at 12:28:51PM +0200, Uros Bizjak wrote:
>> On Wed, Oct 1, 2014 at 12:16 PM, Evgeny Stupachenko
>> wrote:
>> > Getting back to initial patch, is it
Uros Bizjak wrote:
>> On Wed, Oct 1, 2014 at 12:13 AM, Evgeny Stupachenko
>> wrote:
>> > expand_vselect for some reason ignores the expander.
>> > Does it work with expanders?
>> > The comment talks about insn only:
>> > /* Construct (set target
Getting back to initial patch, is it ok?
It fixes gcc.target/i386/pr52252-atom.c for AVX2 make check.
X86 bootstrap is also ok.
2014-10-01 Evgeny Stupachenko
* config/i386/i386.c (expand_vec_perm_palignr): Extend to use AVX2
PALINGR instruction.
* config/i386/i386.c
izjak wrote:
> On Tue, Sep 30, 2014 at 8:08 PM, Uros Bizjak wrote:
>> On Tue, Sep 30, 2014 at 7:06 PM, Uros Bizjak wrote:
>>> On Tue, Sep 30, 2014 at 6:47 PM, Evgeny Stupachenko
>>> wrote:
>>>
>>>> Patch resubmitted from
>>>> https://gcc
>What happens when shift == 16?
We emit just gen_avx2_permv2ti. We don't need additional palignr.
On Tue, Sep 30, 2014 at 9:06 PM, Uros Bizjak wrote:
> On Tue, Sep 30, 2014 at 6:47 PM, Evgeny Stupachenko
> wrote:
>
>> Patch resubmitted from
>> https://gcc.g
r not.
The patch developed similar to define_insn_and_split
"*avx_vperm_broadcast_".
The patch passed x86 bootstrap and make check (+2 new passes for
-march=core-avx2).
Is it ok?
Evgeny
ChangeLog:
2014-09-30 Evgeny Stupachenko
* config/i386/sse.md (avx2_palignrv4di): New.
The test in pr62128 is exactly TEST 22 from
gcc.dg/torture/vshuf-v32qi.c. It will check if the pattern is correct
or not.
Resubmitting patch looks good as current mail thread is already too complicated.
On Wed, Sep 17, 2014 at 6:49 PM, H.J. Lu wrote:
> On Wed, Sep 17, 2014 at 6:01 AM, Evg
It fix "gcc.target/i386/pr52252-atom.c" in core-avx2 make check and pr62128.
On Tue, Sep 16, 2014 at 6:51 PM, H.J. Lu wrote:
> On Tue, Sep 16, 2014 at 6:15 AM, Evgeny Stupachenko
> wrote:
>> PING 2
>>
>> On Mon, Sep 8, 2014 at 2:03 PM, Evgeny Stupachenko
PING 2
On Mon, Sep 8, 2014 at 2:03 PM, Evgeny Stupachenko wrote:
> PING
>
> On Wed, Aug 27, 2014 at 7:50 PM, Evgeny Stupachenko
> wrote:
>> The rotate insn appeared right after expand.
>> I've done it similar to define_insn_and_split "*avx_vperm_broadcast_&quo
PING
On Wed, Aug 27, 2014 at 7:50 PM, Evgeny Stupachenko wrote:
> The rotate insn appeared right after expand.
> I've done it similar to define_insn_and_split "*avx_vperm_broadcast_".
> I don't see any potential losses on splitting that after reload.
>
> On Tu
1 - 100 of 156 matches
Mail list logo
