https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
--- Comment #22 from Jakub Jelinek ---
Author: jakub
Date: Fri Apr 13 08:35:32 2018
New Revision: 259366
URL: https://gcc.gnu.org/viewcvs?rev=259366=gcc=rev
Log:
PR middle-end/81657
* expr.h (enum block_op_methods): Add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
--- Comment #21 from H.J. Lu ---
(In reply to Martin Liška from comment #20)
> Ok, so the PR is still marked as P1, so we should probably focus on it.
> If I'm reading the discussion correctly, there's no consensus about what to
> do?
Please
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
--- Comment #20 from Martin Liška ---
Ok, so the PR is still marked as P1, so we should probably focus on it.
If I'm reading the discussion correctly, there's no consensus about what to do?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
--- Comment #19 from Jakub Jelinek ---
strchr with a c == 0 codepath doesn't have to be the same inner loop as strlen
and for the returning of pointer rather than length can be more efficient than
strlen.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
--- Comment #18 from H.J. Lu ---
(In reply to Wilco from comment #17)
> (In reply to Jakub Jelinek from comment #16)
> > (In reply to Wilco from comment #15)
> > > I don't think it's safe to compare different benchmark results like that.
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
--- Comment #17 from Wilco ---
(In reply to Jakub Jelinek from comment #16)
> (In reply to Wilco from comment #15)
> > I don't think it's safe to compare different benchmark results like that.
> > But yes the kernel for both should be very
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
--- Comment #16 from Jakub Jelinek ---
(In reply to Wilco from comment #15)
> I don't think it's safe to compare different benchmark results like that.
> But yes the kernel for both should be very similar. The key difference is
> that strchr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
--- Comment #14 from Wilco ---
(In reply to Jakub Jelinek from comment #11)
> No matter what, I don't see how you could use much common infrastructure
> here.
> Say if the tailcall pass sees strlen (something) + something being returned,
> it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
--- Comment #15 from Wilco ---
(In reply to H.J. Lu from comment #13)
> (In reply to Wilco from comment #12)
>
> > >
> > > Do you have data to show that?
> >
> > Yes, on x64 I get these timings for a simple function containing just the
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
--- Comment #13 from H.J. Lu ---
(In reply to Wilco from comment #12)
> >
> > Do you have data to show that?
>
> Yes, on x64 I get these timings for a simple function containing just the
> library call:
>
> size 1024 - 13845 21025 14449
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
--- Comment #12 from Wilco ---
(In reply to H.J. Lu from comment #10)
> (In reply to Wilco from comment #9)
> > (In reply to Jakub Jelinek from comment #8)
> > > That just means r240568 caused another regression.
> > > Again, on various targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
--- Comment #11 from Jakub Jelinek ---
No matter what, I don't see how you could use much common infrastructure here.
Say if the tailcall pass sees strlen (something) + something being returned, it
could turn that into strchr (something, 0),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
--- Comment #10 from H.J. Lu ---
(In reply to Wilco from comment #9)
> (In reply to Jakub Jelinek from comment #8)
> > That just means r240568 caused another regression.
> > Again, on various targets strchr is efficient, just on a few ones it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
--- Comment #9 from Wilco ---
(In reply to Jakub Jelinek from comment #8)
> That just means r240568 caused another regression.
> Again, on various targets strchr is efficient, just on a few ones it is not
> and the change was unfortunately done
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
--- Comment #8 from Jakub Jelinek ---
That just means r240568 caused another regression.
Again, on various targets strchr is efficient, just on a few ones it is not and
the change was unfortunately done generically.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
--- Comment #7 from Wilco ---
(In reply to H.J. Lu from comment #6)
> (In reply to Wilco from comment #5)
> > Note there are other optimizations which can block a tailcall, for example:
> >
> > void *f (void *p) { return __builtin_strchr (p,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
--- Comment #6 from H.J. Lu ---
(In reply to Wilco from comment #5)
> Note there are other optimizations which can block a tailcall, for example:
>
> void *f (void *p) { return __builtin_strchr (p, 0); }
This is irrelevant since this refers to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
--- Comment #4 from Martin Liška ---
(In reply to Jakub Jelinek from comment #3)
> As I said earlier, the patch is IMHO wrong and instead ARM/AArch64 should
> implement efficient mempcpy in the library.
> If not, we should have a target hook
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
Andrey Guskov changed:
What|Removed |Added
CC||andrey.y.guskov at intel dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
Martin Liška changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
25 matches
Mail list logo
