On 04/10/2018 06:27 AM, Martin Liška wrote:
> On 04/10/2018 11:19 AM, Jakub Jelinek wrote:
>> On Mon, Apr 09, 2018 at 02:31:04PM +0200, Martin Liška wrote:
>>> gcc/testsuite/ChangeLog:
>>>
>>> 2018-03-28 Martin Liska
>>>
>>> * gcc.dg/string-opt-1.c:
>> I guess you really didn't mean to keep
On Fri, Apr 13, 2018 at 12:10:33PM +, Wilco Dijkstra wrote:
> > Anyway, here is what I think Richard was asking for, that I'm currently
> > bootstrapping/regtesting. It can be easily combined with Martin's target
> > hook if needed, or do it only for
> > endp == 1 && target != const0_rtx && CA
On Fri, Apr 13, 2018 at 5:10 AM, Wilco Dijkstra wrote:
> This patch causes regressions on AArch64 since it now always calls mempcpy
> again, so yes either it would need to be done only for tailcalls (which fixes
> the
> reported regression) or we need Martin's change too so each target can state
Jakub Jelinek wrote:
>On Thu, Apr 12, 2018 at 05:29:35PM +, Wilco Dijkstra wrote:
>> > Depending on what you mean old, I see e.g. in 2010 power7 mempcpy got
>> > added,
>> > in 2013 other power versions, in 2016 s390*, etc. Doing a decent mempcpy
>> > isn't hard if you have asm version of m
On April 13, 2018 12:35:54 AM GMT+02:00, Jakub Jelinek wrote:
>On Thu, Apr 12, 2018 at 07:37:22PM +0200, Jakub Jelinek wrote:
>> On Thu, Apr 12, 2018 at 05:29:35PM +, Wilco Dijkstra wrote:
>> > > Depending on what you mean old, I see e.g. in 2010 power7 mempcpy
>got added,
>> > > in 2013 other
On Thu, Apr 12, 2018 at 07:37:22PM +0200, Jakub Jelinek wrote:
> On Thu, Apr 12, 2018 at 05:29:35PM +, Wilco Dijkstra wrote:
> > > Depending on what you mean old, I see e.g. in 2010 power7 mempcpy got
> > > added,
> > > in 2013 other power versions, in 2016 s390*, etc. Doing a decent mempcpy
On Thu, Apr 12, 2018 at 05:29:35PM +, Wilco Dijkstra wrote:
> > Depending on what you mean old, I see e.g. in 2010 power7 mempcpy got added,
> > in 2013 other power versions, in 2016 s390*, etc. Doing a decent mempcpy
> > isn't hard if you have asm version of memcpy and one spare register.
>
On Thu, Apr 12, 2018 at 04:30:07PM +, Wilco Dijkstra wrote:
> Jakub Jelinek wrote:
> > On Thu, Apr 12, 2018 at 03:53:13PM +, Wilco Dijkstra wrote:
>
> >> The tailcall issue is just a distraction. Historically the handling of
> >> mempcpy
> >> has been horribly inefficient in both GCC and
On Thu, Apr 12, 2018 at 05:17:29PM +0200, Richard Biener wrote:
> >For -Os that is easily measurable regression, for -O2 it depends on the
> >relative speed of memcpy vs. mempcpy and whether one or both of them
> >are in
> >I-cache or not.
>
> Well, then simply unconditionally not generate a libca
Jakub Jelinek wrote:
>On Thu, Apr 12, 2018 at 04:30:07PM +, Wilco Dijkstra wrote:
>> Jakub Jelinek wrote:
>> Frankly I don't see why it is a P1 regression. Do you have a benchmark that
>
>That is how regression priorities are defined.
How can one justify considering this a release blocker wit
On Thu, Apr 12, 2018 at 03:53:13PM +, Wilco Dijkstra wrote:
> Jakub Jelinek wrote:
> > On Thu, Apr 12, 2018 at 03:52:09PM +0200, Richard Biener wrote:
> >> Not sure if I missed some important part of the discussion but
> >> for the testcase we want to preserve the tailcall, right? So
> >> it w
Jakub Jelinek wrote:
> On Thu, Apr 12, 2018 at 03:53:13PM +, Wilco Dijkstra wrote:
>> The tailcall issue is just a distraction. Historically the handling of
>> mempcpy
>> has been horribly inefficient in both GCC and GLIBC for practically all
>> targets.
>> This is why it was decided to def
On Thu, Apr 12, 2018 at 8:53 AM, Wilco Dijkstra wrote:
> So generally it's a good idea to change mempcpy into memcpy by default. It's
> not slower than calling mempcpy even if you have a fast implementation, it's
> faster
> if you use an up to date GLIBC which calls memcpy, and it's significantl
On April 12, 2018 5:38:44 PM GMT+02:00, Jakub Jelinek wrote:
>On Thu, Apr 12, 2018 at 05:17:29PM +0200, Richard Biener wrote:
>> >For -Os that is easily measurable regression, for -O2 it depends on
>the
>> >relative speed of memcpy vs. mempcpy and whether one or both of them
>> >are in
>> >I-cache
Jakub Jelinek wrote:
> On Thu, Apr 12, 2018 at 03:52:09PM +0200, Richard Biener wrote:
>> Not sure if I missed some important part of the discussion but
>> for the testcase we want to preserve the tailcall, right? So
>> it would be enough to set avoid_libcall to
>> endp != 0 && CALL_EXPR_TAILCALL
On April 12, 2018 4:31:12 PM GMT+02:00, Jakub Jelinek wrote:
>On Thu, Apr 12, 2018 at 04:19:38PM +0200, Richard Biener wrote:
>> Well, but that wouldn't be a fix for a regression and IMHO there's
>> no reason for a really lame mempcpy. If targets disgree well,
>
>It is a regression as well, in th
On Thu, Apr 12, 2018 at 04:19:38PM +0200, Richard Biener wrote:
> Well, but that wouldn't be a fix for a regression and IMHO there's
> no reason for a really lame mempcpy. If targets disgree well,
It is a regression as well, in the past we've emitted mempcpy when user
wrote mempcpy, now we don't.
On Thu, Apr 12, 2018 at 03:52:09PM +0200, Richard Biener wrote:
> Not sure if I missed some important part of the discussion but
> for the testcase we want to preserve the tailcall, right? So
> it would be enough to set avoid_libcall to
> endp != 0 && CALL_EXPR_TAILCALL (exp) (and thus also handle
On Thu, 12 Apr 2018, Jakub Jelinek wrote:
> On Thu, Apr 12, 2018 at 03:52:09PM +0200, Richard Biener wrote:
> > Not sure if I missed some important part of the discussion but
> > for the testcase we want to preserve the tailcall, right? So
> > it would be enough to set avoid_libcall to
> > endp !
On Thu, 12 Apr 2018, Martin Liška wrote:
> Hi.
>
> I'm reminding review request from Richi for generic part
> and Uros/Honza for target part.
Not sure if I missed some important part of the discussion but
for the testcase we want to preserve the tailcall, right? So
it would be enough to set avo
> Hi.
>
> I'm reminding review request from Richi for generic part
> and Uros/Honza for target part.
OK for i386 bits.
Honza
>
> Thanks,
> Martin
Hi.
I'm reminding review request from Richi for generic part
and Uros/Honza for target part.
Thanks,
Martin
On 04/10/2018 11:19 AM, Jakub Jelinek wrote:
> On Mon, Apr 09, 2018 at 02:31:04PM +0200, Martin Liška wrote:
>> gcc/testsuite/ChangeLog:
>>
>> 2018-03-28 Martin Liska
>>
>> * gcc.dg/string-opt-1.c:
>
> I guess you really didn't mean to keep the above entry around, just the one
> below, rig
On Mon, Apr 09, 2018 at 02:31:04PM +0200, Martin Liška wrote:
> gcc/testsuite/ChangeLog:
>
> 2018-03-28 Martin Liska
>
> * gcc.dg/string-opt-1.c:
I guess you really didn't mean to keep the above entry around, just the one
below, right?
> gcc/testsuite/ChangeLog:
>
> 2018-03-14 Martin
Hi.
I'm sending updated version of the patch.
Patch can bootstrap on ppc64le-redhat-linux and x86_64-linux and survives
regression tests.
Martin
>From 6d19b1bf0c28a683e1458e16943e34bb547d36d6 Mon Sep 17 00:00:00 2001
From: marxin
Date: Wed, 14 Mar 2018 09:44:18 +0100
Subject: [PATCH] Introduce
PING^1
On 03/29/2018 02:31 PM, Martin Liška wrote:
> On 03/29/2018 02:25 PM, Jakub Jelinek wrote:
>> On Thu, Mar 29, 2018 at 01:28:13PM +0200, Martin Liška wrote:
>>> On 03/28/2018 06:36 PM, Jakub Jelinek wrote:
On Wed, Mar 28, 2018 at 06:30:21PM +0200, Martin Liška wrote:
> --- a/gcc/con
On Thu, Mar 29, 2018 at 01:28:13PM +0200, Martin Liška wrote:
> On 03/28/2018 06:36 PM, Jakub Jelinek wrote:
> > On Wed, Mar 28, 2018 at 06:30:21PM +0200, Martin Liška wrote:
> > > --- a/gcc/config/linux.c
> > > +++ b/gcc/config/linux.c
> > > @@ -37,3 +37,24 @@ linux_libc_has_function (enum functio
On 03/29/2018 02:25 PM, Jakub Jelinek wrote:
On Thu, Mar 29, 2018 at 01:28:13PM +0200, Martin Liška wrote:
On 03/28/2018 06:36 PM, Jakub Jelinek wrote:
On Wed, Mar 28, 2018 at 06:30:21PM +0200, Martin Liška wrote:
--- a/gcc/config/linux.c
+++ b/gcc/config/linux.c
@@ -37,3 +37,24 @@ linux_libc_
On Thu, Mar 29, 2018 at 4:28 AM, Martin Liška wrote:
> On 03/28/2018 06:36 PM, Jakub Jelinek wrote:
>>
>> On Wed, Mar 28, 2018 at 06:30:21PM +0200, Martin Liška wrote:
>>>
>>> --- a/gcc/config/linux.c
>>> +++ b/gcc/config/linux.c
>>> @@ -37,3 +37,24 @@ linux_libc_has_function (enum function_class
On 03/28/2018 06:36 PM, Jakub Jelinek wrote:
On Wed, Mar 28, 2018 at 06:30:21PM +0200, Martin Liška wrote:
--- a/gcc/config/linux.c
+++ b/gcc/config/linux.c
@@ -37,3 +37,24 @@ linux_libc_has_function (enum function_class fn_class)
return false;
}
+
+/* This hook determines whether a fu
On Wed, Mar 28, 2018 at 06:30:21PM +0200, Martin Liška wrote:
> --- a/gcc/config/linux.c
> +++ b/gcc/config/linux.c
> @@ -37,3 +37,24 @@ linux_libc_has_function (enum function_class fn_class)
>
>return false;
> }
> +
> +/* This hook determines whether a function from libc has a fast
> imple
On 03/28/2018 04:31 PM, Jakub Jelinek wrote:
On Wed, Mar 28, 2018 at 04:18:45PM +0200, Martin Liška wrote:
2018-03-14 Martin Liska
PR middle-end/81657
* builtins.c (expand_builtin_memory_copy_args): Handle situation
when libc library provides a fast mempcpy implementa
On Wed, Mar 28, 2018 at 04:18:45PM +0200, Martin Liška wrote:
> 2018-03-14 Martin Liska
>
> PR middle-end/81657
> * builtins.c (expand_builtin_memory_copy_args): Handle situation
> when libc library provides a fast mempcpy implementation/
> * config/i386/i386-protos.h (g
On 03/21/2018 11:34 AM, Jakub Jelinek wrote:
On Wed, Mar 14, 2018 at 02:54:00PM +0100, Martin Liška wrote:
The variable is not named very well, shouldn't it be avoid_libcall or
something similar? Perhaps the variable should have a comment describing
what it is. Do you need separate argument fo
On Wed, Mar 14, 2018 at 02:54:00PM +0100, Martin Liška wrote:
> > The variable is not named very well, shouldn't it be avoid_libcall or
> > something similar? Perhaps the variable should have a comment describing
> > what it is. Do you need separate argument for that bool and
> > is_move_done, ra
PING^1
On 03/14/2018 02:54 PM, Martin Liška wrote:
On 03/14/2018 02:07 PM, Jakub Jelinek wrote:
On Wed, Mar 14, 2018 at 01:54:39PM +0100, Martin Liška wrote:
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -3651,13 +3651,24 @@ expand_builtin_memory_copy_args (tree dest, tree src,
tree len,
s
On 03/14/2018 02:07 PM, Jakub Jelinek wrote:
> On Wed, Mar 14, 2018 at 01:54:39PM +0100, Martin Liška wrote:
>> --- a/gcc/builtins.c
>> +++ b/gcc/builtins.c
>> @@ -3651,13 +3651,24 @@ expand_builtin_memory_copy_args (tree dest, tree
>> src, tree len,
>>src_mem = get_memory_rtx (src, len);
>>
On Wed, Mar 14, 2018 at 02:08:07PM +0100, Martin Liška wrote:
> > diff --git a/gcc/testsuite/gcc.c-torture/execute/builtins/mempcpy.c
> > b/gcc/testsuite/gcc.c-torture/execute/builtins/mempcpy.c
> > index d82e2232d7b..91e1c87f83f 100644
> > --- a/gcc/testsuite/gcc.c-torture/execute/builtins/mempcpy
On Wed, Mar 14, 2018 at 01:54:39PM +0100, Martin Liška wrote:
> --- a/gcc/builtins.c
> +++ b/gcc/builtins.c
> @@ -3651,13 +3651,24 @@ expand_builtin_memory_copy_args (tree dest, tree src,
> tree len,
>src_mem = get_memory_rtx (src, len);
>set_mem_align (src_mem, src_align);
>
> + bool i
On 03/14/2018 01:57 PM, H.J. Lu wrote:
> On Wed, Mar 14, 2018 at 5:54 AM, Martin Liška wrote:
>> On 03/13/2018 04:23 PM, Jakub Jelinek wrote:
>>> On Tue, Mar 13, 2018 at 04:19:21PM +0100, Martin Liška wrote:
> Yes, see e.g. TARGET_LIBC_HAS_FUNCTION target hook,
> where in particular linux_
On Wed, Mar 14, 2018 at 5:54 AM, Martin Liška wrote:
> On 03/13/2018 04:23 PM, Jakub Jelinek wrote:
>> On Tue, Mar 13, 2018 at 04:19:21PM +0100, Martin Liška wrote:
Yes, see e.g. TARGET_LIBC_HAS_FUNCTION target hook,
where in particular linux_libc_has_function deals with various C librar
On 03/13/2018 04:23 PM, Jakub Jelinek wrote:
> On Tue, Mar 13, 2018 at 04:19:21PM +0100, Martin Liška wrote:
>>> Yes, see e.g. TARGET_LIBC_HAS_FUNCTION target hook,
>>> where in particular linux_libc_has_function deals with various C libraries.
>>> Of course, in this case you need another target ho
On Tue, Mar 13, 2018 at 04:19:21PM +0100, Martin Liška wrote:
> > Yes, see e.g. TARGET_LIBC_HAS_FUNCTION target hook,
> > where in particular linux_libc_has_function deals with various C libraries.
> > Of course, in this case you need another target hook, that is dependent both
> > on the target ba
On 03/13/2018 09:32 AM, Jakub Jelinek wrote:
On Tue, Mar 13, 2018 at 09:24:11AM +0100, Martin Liška wrote:
On 03/12/2018 10:39 AM, Marc Glisse wrote:
On Mon, 12 Mar 2018, Martin Liška wrote:
This is fix for the PR that introduces a new target macro. Using the macro
one can say that a target h
On Tue, Mar 13, 2018 at 9:32 AM, Jakub Jelinek wrote:
> On Tue, Mar 13, 2018 at 09:24:11AM +0100, Martin Liška wrote:
>> On 03/12/2018 10:39 AM, Marc Glisse wrote:
>> > On Mon, 12 Mar 2018, Martin Liška wrote:
>> >
>> > > This is fix for the PR that introduces a new target macro. Using the
>> > >
On Tue, Mar 13, 2018 at 09:24:11AM +0100, Martin Liška wrote:
> On 03/12/2018 10:39 AM, Marc Glisse wrote:
> > On Mon, 12 Mar 2018, Martin Liška wrote:
> >
> > > This is fix for the PR that introduces a new target macro. Using the macro
> > > one can say that a target has a fast mempcpy and thus i
On 03/12/2018 10:39 AM, Marc Glisse wrote:
On Mon, 12 Mar 2018, Martin Liška wrote:
This is fix for the PR that introduces a new target macro. Using the macro
one can say that a target has a fast mempcpy and thus it's preferred to be used
if possible.
Patch can bootstrap on ppc64le-redhat-linu
On Mon, Mar 12, 2018 at 09:57:09AM +0100, Martin Liška wrote:
> Hi.
>
> This is fix for the PR that introduces a new target macro. Using the macro
> one can say that a target has a fast mempcpy and thus it's preferred to be
> used
> if possible.
>
> Patch can bootstrap on ppc64le-redhat-linux an
On Mon, Mar 12, 2018 at 9:57 AM, Martin Liška wrote:
> Hi.
>
> This is fix for the PR that introduces a new target macro. Using the macro
Don't add new target macros, use target hooks.
> one can say that a target has a fast mempcpy and thus it's preferred to be
> used
> if possible.
>
> Patch c
On Mon, 12 Mar 2018, Martin Liška wrote:
This is fix for the PR that introduces a new target macro. Using the macro
one can say that a target has a fast mempcpy and thus it's preferred to be used
if possible.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
I also test
Hi.
This is fix for the PR that introduces a new target macro. Using the macro
one can say that a target has a fast mempcpy and thus it's preferred to be used
if possible.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
I also tested on x86_64-linux-gnu.
Ready to be in
51 matches
Mail list logo
