Hello,
On 09 Sep 13:50, Uros Bizjak wrote:
> OK.
Checked into main trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00286.html
--
Thanks, K
On Mon, Sep 9, 2013 at 12:22 PM, Michael V. Zolotukhin
wrote:
>> > Is mtune ok here?
>> Yes.
> Thanks, fixed. Ok to commit?
> I verified that the test fails without fix in i386.c and passes with it.
>
> Changelog:
> gcc:
> 2013-09-09 Michael Zolotukhin
>
> * config/i386/i386.c (ix86_ex
> > Is mtune ok here?
> Yes.
Thanks, fixed. Ok to commit?
I verified that the test fails without fix in i386.c and passes with it.
Changelog:
gcc:
2013-09-09 Michael Zolotukhin
* config/i386/i386.c (ix86_expand_movmem): Fix epilogue generation.
gcc/testsuite:
2013-09-09 Michael Zolo
On Mon, Sep 9, 2013 at 12:17 PM, Jakub Jelinek wrote:
> On Mon, Sep 09, 2013 at 02:12:35PM +0400, Michael V. Zolotukhin wrote:
>> > No -march in runtime tests, please.
>> Is mtune ok here?
>
> Please verify that with the s/-march/-mtune/ change without the i386.c fix
> the testcase
It will fail,
On Mon, Sep 09, 2013 at 02:12:35PM +0400, Michael V. Zolotukhin wrote:
> > No -march in runtime tests, please.
> Is mtune ok here?
Please verify that with the s/-march/-mtune/ change without the i386.c fix the
testcase
will fail with
make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}
On Mon, Sep 9, 2013 at 12:12 PM, Michael V. Zolotukhin
wrote:
>> No -march in runtime tests, please.
> Is mtune ok here?
Yes.
Uros.
> No -march in runtime tests, please.
Is mtune ok here?
Michael
> Uros.
On Mon, Sep 9, 2013 at 11:23 AM, Michael V. Zolotukhin
wrote:
>> Please don't introduce new *.x files, for tests where you need something
>> like that just stick it into gcc.dg/torture/ instead and use normal dg stuff
>> in there.
> Thanks, fixed. Ok to commit?
No -march in runtime tests, please
> Please don't introduce new *.x files, for tests where you need something
> like that just stick it into gcc.dg/torture/ instead and use normal dg stuff
> in there.
Thanks, fixed. Ok to commit?
Changelog:
gcc:
2013-09-09 Michael Zolotukhin
* config/i386/i386.c (ix86_expand_movmem): F
On Mon, Sep 09, 2013 at 01:09:12PM +0400, Michael V. Zolotukhin wrote:
> I've never written torture tests before, could you please check if I did it
> right?
Please don't introduce new *.x files, for tests where you need something
like that just stick it into gcc.dg/torture/ instead and use normal
> I think it is worthwhile, various targets have many different ways to expand
> memcpy, admittedly i?86/x86_64 probably the biggest number of these, and
> while right now you've encountered it on ia32 with certain options doesn't
> mean that in a few years it couldn't hit some unrelated target, ar
On Mon, Sep 09, 2013 at 11:52:49AM +0400, Michael V. Zolotukhin wrote:
> > I don't see anything i386 specific on the testcase, except the flags,
> > and don't see why you need -fno-common in there, there are no global vars.
> > So, I think it would be better to stick it into gcc.dg/torture/, drop
>
> I don't see anything i386 specific on the testcase, except the flags,
> and don't see why you need -fno-common in there, there are no global vars.
> So, I think it would be better to stick it into gcc.dg/torture/, drop
> dg-require-* line and instead just add
> /* { dg-additional-options "-march=
On Mon, Sep 09, 2013 at 11:42:05AM +0400, Michael V. Zolotukhin wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/memcpy-2.c
> @@ -0,0 +1,22 @@
> +/* { dg-do run } */
> +/* { dg-require-effective-target ia32 } */
> +/* { dg-options "-O2 -march=pentiumpro -minline-all-stringops -fno-commo
On Mon, Sep 9, 2013 at 9:42 AM, Michael V. Zolotukhin
wrote:
>> OK,
>> Would you mind adding a testcase?
> Thanks, here is the patch with Eric's test.
> OK to commit?
>
> Changelog:
> gcc:
> 2013-09-09 Michael Zolotukhin
>
> * config/i386/i386.c (ix86_expand_movmem): Fix epilogue genera
> OK,
> Would you mind adding a testcase?
Thanks, here is the patch with Eric's test.
OK to commit?
Changelog:
gcc:
2013-09-09 Michael Zolotukhin
* config/i386/i386.c (ix86_expand_movmem): Fix epilogue generation.
gcc/testsuite:
2013-09-09 Michael Zolotukhin
* gcc.target/i
> Hi HJ,
> You were right, and the change from epilogue_size_needed to size_needed was
> the
> rootcause of the bug.
> Here is the obvious fix for that, regtested and bootstrapped on i386/x86_64.
>
> Is it OK for trunk?
>
> Changelog:
> 2013-09-09 Michael Zolotukhin
>
> * config/i386/i
Hi HJ,
You were right, and the change from epilogue_size_needed to size_needed was the
rootcause of the bug.
Here is the obvious fix for that, regtested and bootstrapped on i386/x86_64.
Is it OK for trunk?
Changelog:
2013-09-09 Michael Zolotukhin
* config/i386/i386.c (ix86_expand_movm
> Michael, why did you change epilogue_size_needed to size_needed
> here? It looks wrong to me.
This function was changed in several places and meaning of
'size_needed' and 'epilogue_size_needed' could've been changed. It
needs more careful examination and I'll do it shortly.
Briefly, I significan
On Tue, Sep 3, 2013 at 12:01 PM, Eric Botcazou wrote:
>> Changes were checked into trunk:
>> http://gcc.gnu.org/ml/gcc-cvs/2013-07/msg00179.html
>
> The patch miscompiles the MPFR library on x86 Pentium Pro. Reduced testcase
> attached, compile for x86 with -mtune=pentiumpro.
>
The change in que
On Tue, Sep 3, 2013 at 12:05 PM, Michael V. Zolotukhin
wrote:
>> The patch miscompiles the MPFR library on x86 Pentium Pro. Reduced testcase
>> attached, compile for x86 with -mtune=pentiumpro.
> Thanks, I'll look at that in the nearest future.
>
> Best regards, Michael
The problem is
t
> Changes were checked into trunk:
> http://gcc.gnu.org/ml/gcc-cvs/2013-07/msg00179.html
The patch miscompiles the MPFR library on x86 Pentium Pro. Reduced testcase
attached, compile for x86 with -mtune=pentiumpro.
--
Eric Botcazoustatic void __attribute__((noinline, noclone))
my_memcpy (char
> The patch miscompiles the MPFR library on x86 Pentium Pro. Reduced testcase
> attached, compile for x86 with -mtune=pentiumpro.
Thanks, I'll look at that in the nearest future.
Best regards, Michael
> Changes were checked into trunk:
> http://gcc.gnu.org/ml/gcc-cvs/2013-07/msg00179.html
Thanks, Kirill
>> There is a lot of things we can do about string operations, taking
>> incremental steps is good
>> plan.
Then my next step will be implementation of vector_loop for memset
with 0. Thanks fo
Hello,
> Yes, this patch is OK (I meant my previous mail as an approval).
> There is a lot of things we can do about string operations, taking
> incremental steps is good
> plan.
Changes were checked into trunk:
http://gcc.gnu.org/ml/gcc-cvs/2013-07/msg00179.html
Thanks, K
> > I agree, but anyway we need some tests to measure performance - whether
> > these tests are Specs or some others.
> >
> >
> > I attached the updated patch - it's the same as the previous, but
> > without emit-rtl.c changes. Is it ok for trunk?
Yes, this patch is OK (I meant my previous mail as
Ping.
On 2 July 2013 18:37, Michael Zolotukhin wrote:
> Hi guys,
> Thanks for the review and for your responses - please find my answers
> below.
>
>> Yes, I looked on the patch in detail this week (I am currently on a travel
>> with
>> sporadic internet access and my days before leaving was ext
Hi guys,
Thanks for the review and for your responses - please find my answers
below.
> Yes, I looked on the patch in detail this week (I am currently on a travel
> with
> sporadic internet access and my days before leaving was extremely hectic).
> The
> patch is OK except for the expr.c bits I
On Sun, Jun 30, 2013 at 11:06:47AM +0200, Jan Hubicka wrote:
> > On Tue, Jun 25, 2013 at 3:36 PM, Michael Zolotukhin
> > wrote:
> > > Ping.
> > >
> > > On 20 June 2013 20:56, Michael Zolotukhin
> > > wrote:
> > >> It seems that one of the tests needed a small fix.
> > >> Attached is a corrected v
> On Tue, Jun 25, 2013 at 3:36 PM, Michael Zolotukhin
> wrote:
> > Ping.
> >
> > On 20 June 2013 20:56, Michael Zolotukhin
> > wrote:
> >> It seems that one of the tests needed a small fix.
> >> Attached is a corrected version.
>
> Jan, do you plan to review this patch? It touches the area that
On Tue, Jun 25, 2013 at 3:36 PM, Michael Zolotukhin
wrote:
> Ping.
>
> On 20 June 2013 20:56, Michael Zolotukhin
> wrote:
>> It seems that one of the tests needed a small fix.
>> Attached is a corrected version.
Jan, do you plan to review this patch? It touches the area that you
worked on extens
Ping.
On 20 June 2013 20:56, Michael Zolotukhin
wrote:
> It seems that one of the tests needed a small fix.
> Attached is a corrected version.
>
> On 20 June 2013 17:16, Michael Zolotukhin
> wrote:
>> Hi,
>> I added two tests to verify we generate vector instructions when
>> vector_loop is used.
It seems that one of the tests needed a small fix.
Attached is a corrected version.
On 20 June 2013 17:16, Michael Zolotukhin
wrote:
> Hi,
> I added two tests to verify we generate vector instructions when
> vector_loop is used.
> Is the patch ok with that change?
>
> Thanks, Michael
>
> On 5 Jun
Hi,
I added two tests to verify we generate vector instructions when
vector_loop is used.
Is the patch ok with that change?
Thanks, Michael
On 5 June 2013 18:10, Michael Zolotukhin wrote:
> I'll prepare some tests shortly,
> What about the rest questions?
>
> Thanks, Michael
>
> On 15 May 2013 1
I'll prepare some tests shortly,
What about the rest questions?
Thanks, Michael
On 15 May 2013 19:45, H.J. Lu wrote:
> On Wed, May 15, 2013 at 5:47 AM, Michael Zolotukhin
> wrote:
>> Hi HJ,
>>> You use Pmode as the largest integer mode. Is word_mode better
>>> than Pmode since word_mode is DI
On Wed, May 15, 2013 at 5:47 AM, Michael Zolotukhin
wrote:
> Hi HJ,
>> You use Pmode as the largest integer mode. Is word_mode better
>> than Pmode since word_mode is DI and Pmode may be SI for x32.
> I updated the patch to use word_mode instead of Pmode. Bootstrap,
> make check and Specs2000 ar
Hi HJ,
> You use Pmode as the largest integer mode. Is word_mode better
> than Pmode since word_mode is DI and Pmode may be SI for x32.
I updated the patch to use word_mode instead of Pmode. Bootstrap,
make check and Specs2000 are ok.
Thanks, Michael
On 14 May 2013 19:55, H.J. Lu wrote:
> On T
On Tue, May 14, 2013 at 7:34 AM, Michael Zolotukhin
wrote:
> Hi,
> I attached an updated version of the patch. Looks like the 64-bit issue is
> resolved in it (now a vector mode is explicitly chosen instead of TI- or
> another integer mode). Also, some of remarks are fixed in it - some
> others
Forgot to add Uros - adding now.
On 18 April 2013 15:53, Michael Zolotukhin
wrote:
> Hi,
> Jan, thanks for the review, I hope to prepare an updated version of the patch
> shortly. Please see my answers to your comments below.
>
> Uros, there is a question of a better approach for generation of w
Hi,
Jan, thanks for the review, I hope to prepare an updated version of the patch
shortly. Please see my answers to your comments below.
Uros, there is a question of a better approach for generation of wide moves.
Could you please comment it (see details in bullets 3 and 5)?
1.
> +static int sma
@@ -2392,6 +2392,7 @@ static void ix86_set_current_function (tree);
static unsigned int ix86_minimum_incoming_stack_boundary (bool);
static enum calling_abi ix86_function_abi (const_tree);
+static int smallest_pow2_greater_than (int);
Perhaps it is easier to use existing 1<> 1;
+ move_mode =
>
> Bootstrap/make check/Specs2k are passing on i686 and x86_64.
Thanks for returning to this!
glibc has quite comprehensive testsuite for stringop. It may be useful to test
it
with -minline-all-stringop -mstringop-stategy=vector
I tested the patch on my core notebook and my memcpy micro bench
On Fri, Apr 12, 2013 at 01:08:15PM +0400, Michael Zolotukhin wrote:
> > I did some profiling of builtin implementation, download this
> > http://kam.mff.cuni.cz/~ondra/memcpy_profile_builtin.tar.bz2
> Nice data, thanks!
> Could you please describe what is memcpy_new_builtin here? Is it how
> GCC ex
> I did some profiling of builtin implementation, download this
> http://kam.mff.cuni.cz/~ondra/memcpy_profile_builtin.tar.bz2
Nice data, thanks!
Could you please describe what is memcpy_new_builtin here? Is it how
GCC expanded memcpy with this patch?
Is this a comparison between libcall, libcall w
On Thu, Apr 11, 2013 at 04:32:30PM +0400, Michael Zolotukhin wrote:
> > 128 is about upper bound you can expand with sse moves.
> > Tuning did not take into account code size and measured only when code
> > is in tigth loop.
> > For GPR-moves limit is around 64.
> Thanks for the data - I've not per
> 128 is about upper bound you can expand with sse moves.
> Tuning did not take into account code size and measured only when code
> is in tigth loop.
> For GPR-moves limit is around 64.
Thanks for the data - I've not performed measurements with this
implementation yet, but we surely should adjust
On Wed, Apr 10, 2013 at 09:53:09PM +0400, Michael Zolotukhin wrote:
> > Hi, I am writing memcpy for libc. It avoids computed jump and has is
> > much faster on small strings (variant for sandy bridge attached.
>
> I'm not sure I get what you meant - could you please explain what is
> computed jump
> Hi, I am writing memcpy for libc. It avoids computed jump and has is
> much faster on small strings (variant for sandy bridge attached.
I'm not sure I get what you meant - could you please explain what is
computed jumps?
> You must also check performance with cold instruction cache.
> Now memcp
On Wed, Apr 10, 2013 at 08:14:30PM +0400, Michael Zolotukhin wrote:
> Hi,
> This patch adds a new algorithm of expanding movmem in x86 and a bit
> refactor existing implementation. This is a reincarnation of the patch
> that was sent wasn't checked couple of years ago - now I reworked it
> from scr
Hi,
This patch adds a new algorithm of expanding movmem in x86 and a bit
refactor existing implementation. This is a reincarnation of the patch
that was sent wasn't checked couple of years ago - now I reworked it
from scratch and divide into several more manageable parts.
For now this algorithm is
50 matches
Mail list logo
