https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
--- Comment #21 from Martin Liška ---
Author: marxin
Date: Mon May 20 07:55:00 2019
New Revision: 271400
URL: https://gcc.gnu.org/viewcvs?rev=271400=gcc=rev
Log:
Come up with hook libc_has_fast_function (PR middle-end/90263).
2019-05-20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
--- Comment #20 from Wilco ---
(In reply to Martin Liška from comment #19)
> Created attachment 46265 [details]
> Patch candidate v2
>
> Update patch that should be fine. Tests on x86_64 work except:
> FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
Martin Liška changed:
What|Removed |Added
Attachment #46262|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
--- Comment #18 from Wilco ---
(In reply to Martin Liška from comment #14)
> Created attachment 46262 [details]
> Patch candidate
>
> Patch candidate that handles:
>
> $ cat ~/Programming/testcases/mempcpy.c
> int *mempcopy2 (int *p, int *q,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
--- Comment #17 from Wilco ---
(In reply to Wilco from comment #16)
> (In reply to Martin Sebor from comment #15)
> > I just noticed I have been misreading mempcpy as memccpy and so making no
> > sense. Sorry about that! Please ignore my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
--- Comment #16 from Wilco ---
(In reply to Martin Sebor from comment #15)
> I just noticed I have been misreading mempcpy as memccpy and so making no
> sense. Sorry about that! Please ignore my comments.
I see, yes we have too many and the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
--- Comment #15 from Martin Sebor ---
I just noticed I have been misreading mempcpy as memccpy and so making no
sense. Sorry about that! Please ignore my comments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
--- Comment #14 from Martin Liška ---
Created attachment 46262
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46262=edit
Patch candidate
Patch candidate that handles:
$ cat ~/Programming/testcases/mempcpy.c
int *mempcopy2 (int *p, int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
--- Comment #13 from Martin Sebor ---
I mean an equivalent of the following (with suitable symbol linkage):
void* memccpy (void *d, const void *s, int c, size_t n)
{
// efficient memccpy, perhaps in assembly
}
void* memcpy (void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
--- Comment #12 from Wilco ---
(In reply to Martin Sebor from comment #11)
> My concern is that transforming memccpy to memcpy would leave little
> incentive for libraries like glibc to provide a more optimal implementation.
> Would implementing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
--- Comment #11 from Martin Sebor ---
My concern is that transforming memccpy to memcpy would leave little incentive
for libraries like glibc to provide a more optimal implementation. Would
implementing the function simply as memcpy and having
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
--- Comment #10 from Martin Liška ---
(In reply to Wilco from comment #6)
> (In reply to Martin Liška from comment #5)
> > The discussion looks familiar to me. Isn't that PR70140, where I was
> > suggesting something like:
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
--- Comment #9 from Wilco ---
(In reply to Martin Sebor from comment #7)
> Rather than unconditionally transforming mempcpy to memcpy I would prefer to
> see libc implementations of memccpy optimized. WG14 N2349 discusses a
> rationale for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
Martin Sebor changed:
What|Removed |Added
Keywords||missed-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
--- Comment #6 from Wilco ---
(In reply to Martin Liška from comment #5)
> The discussion looks familiar to me. Isn't that PR70140, where I was
> suggesting something like:
>
> https://marc.info/?l=gcc-patches=150166433909242=2
>
> with a new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
--- Comment #4 from Wilco ---
(In reply to Jakub Jelinek from comment #3)
> Because then you penalize properly maintained targets which do have
> efficient mempcpy. And even if some targets don't have efficient mempcpy
> right now, that doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
--- Comment #3 from Jakub Jelinek ---
Because then you penalize properly maintained targets which do have efficient
mempcpy. And even if some targets don't have efficient mempcpy right now, that
doesn't mean they can't have it in the future.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
--- Comment #2 from Wilco ---
(In reply to Jakub Jelinek from comment #1)
> As stated several times in the past, I strongly disagree.
Why? GCC already does this for bzero and bcopy.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
23 matches
Mail list logo
