On 09/16/2016 07:28 AM, Wilco Dijkstra wrote:
I noticed rawmemchr taking non-trivial amounts of time in various profiles
despite no use of rawmemchr in any of the source code. It's apparently a
common idiom to use strchr (s, 0) to find the end of a string.
A bit of a surprise, but it is what it
Bernd Schmidt wrote:
> On 09/15/2016 03:38 PM, Wilco Dijkstra wrote:
> > __rawmemchr is not the fastest on any target I tried, including x86,
>
> Interesting. Care to share your test program? I just looked at the libc
> sources and strlen/rawmemchr are practically identical code so I'd
> expect a
Jakub Jelinek
>
> Those are the generic definitions, all targets that care about performance
> obviously should replace them with assembly code.
No, that's exactly my point, it is not true that it is always best to write
assembly
code. For example there is absolutely no benefit in writing an opt
On Thu, Sep 15, 2016 at 03:27:52PM +, Wilco Dijkstra wrote:
> That's best done GCC as a general optimization as currently mempcpy is not
> handled efficiently (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70140),
> and it avoids having to repeat this for every C library out there...
>
> g
From: Jakub Jelinek
> On Thu, Sep 15, 2016 at 02:55:48PM +, Wilco Dijkstra wrote:
>> stpcpy is not conceptually the same, but for mempcpy, yes. By default
>> it's converted into memcpy in the GLIBC headers and the generic
>> implementation.
>>
>> stpcpy uses strlen and memcpy which is genera
Jakub Jelinek wrote:
On Thu, Sep 15, 2016 at 03:16:52PM +0100, Szabolcs Nagy wrote:
> >
> > from libc point of view, rawmemchr is a rarely used
> > nonstandard function that should be optimized for size.
> > (glibc does not do this now, but it should in my opinion.)
>
> rawmemchr with 0 is to strl
On Thu, Sep 15, 2016 at 02:55:48PM +, Wilco Dijkstra wrote:
> Jakub Jelinek wrote:
> On Thu, Sep 15, 2016 at 03:16:52PM +0100, Szabolcs Nagy wrote:
> > >
> > > from libc point of view, rawmemchr is a rarely used
> > > nonstandard function that should be optimized for size.
> > > (glibc does no
On Thu, Sep 15, 2016 at 03:16:52PM +0100, Szabolcs Nagy wrote:
> On 15/09/16 14:49, Jakub Jelinek wrote:
> > On Thu, Sep 15, 2016 at 01:38:45PM +, Wilco Dijkstra wrote:
> >> __rawmemchr is not the fastest on any target I tried, including x86, so
> >> GLIBC's
> >> current default behaviour of a
On 15/09/16 14:49, Jakub Jelinek wrote:
> On Thu, Sep 15, 2016 at 01:38:45PM +, Wilco Dijkstra wrote:
>> __rawmemchr is not the fastest on any target I tried, including x86, so
>> GLIBC's
>> current default behaviour of always using __rawmemchr is inefficient. GCC
>> doesn't
>> support __rawm
On 09/15/2016 03:38 PM, Wilco Dijkstra wrote:
__rawmemchr is not the fastest on any target I tried, including x86,
Interesting. Care to share your test program? I just looked at the libc
sources and strlen/rawmemchr are practically identical code so I'd
expect any difference to be lost in the
On Thu, Sep 15, 2016 at 01:38:45PM +, Wilco Dijkstra wrote:
> __rawmemchr is not the fastest on any target I tried, including x86, so
> GLIBC's
> current default behaviour of always using __rawmemchr is inefficient. GCC
> doesn't
> support __rawmemchr at all, so the strlen optimization can't
Richard Biener wrote:
> On Wed, Sep 14, 2016 at 3:45 PM, Jakub Jelinek wrote:
> > On Wed, Sep 14, 2016 at 03:41:33PM +0200, Richard Biener wrote:
> >> > We've seen several different proposals for where/how to do this
> >> > simplification, why did you
> >> > say strlenopt is best? It would be an
On Thu, Sep 15, 2016 at 09:52:34AM +0200, Richard Biener wrote:
> On Wed, Sep 14, 2016 at 3:45 PM, Jakub Jelinek wrote:
> > On Wed, Sep 14, 2016 at 03:41:33PM +0200, Richard Biener wrote:
> >> > We've seen several different proposals for where/how to do this
> >> > simplification, why did you
> >
On Wed, Sep 14, 2016 at 3:45 PM, Jakub Jelinek wrote:
> On Wed, Sep 14, 2016 at 03:41:33PM +0200, Richard Biener wrote:
>> > We've seen several different proposals for where/how to do this
>> > simplification, why did you
>> > say strlenopt is best? It would be an unconditional strchr (a, 0) -> a
On 14/09/16 14:45, Jakub Jelinek wrote:
> I think for the middle-end, using strchr (a, 0) as canonical instead of a +
> strlen (a)
> is better, and at expansion time we can decide what to use (a + strlen (a)
> if you'd expand strlen inline, rather than as a function call, or
> __rawmemchr (which i
On Wed, Sep 14, 2016 at 03:41:33PM +0200, Richard Biener wrote:
> > We've seen several different proposals for where/how to do this
> > simplification, why did you
> > say strlenopt is best? It would be an unconditional strchr (a, 0) -> a +
> > strlen (a) rewrite,
> > ie. completely unrelated to
On Tue, Sep 13, 2016 at 2:36 PM, Wilco Dijkstra wrote:
> Richard Biener wrote:
>> On Wed, May 18, 2016 at 2:29 PM, Wilco Dijkstra
>> wrote:
>>> Richard Biener wrote:
>>>
Yeah ;) I'm currently bootstrapping/testing the patch that makes it
possible to
write all this in match.pd.
On Tue, 2016-09-13 at 12:36 +, Wilco Dijkstra wrote:
> Richard Biener wrote:
> >
> > On Wed, May 18, 2016 at 2:29 PM, Wilco Dijkstra > .com> wrote:
> > >
> > > Richard Biener wrote:
> > >
> > > >
> > > > Yeah ;) I'm currently bootstrapping/testing the patch that
> > > > makes it possible
Richard Biener wrote:
> On Wed, May 18, 2016 at 2:29 PM, Wilco Dijkstra
> wrote:
>> Richard Biener wrote:
>>
>>> Yeah ;) I'm currently bootstrapping/testing the patch that makes it
>>> possible to
>>> write all this in match.pd.
>>
>> So what was the conclusion? Improving match.pd to be able t
On Wed, May 18, 2016 at 2:29 PM, Wilco Dijkstra wrote:
> Richard Biener wrote:
>>
>> Yeah ;) I'm currently bootstrapping/testing the patch that makes it
>> possible to
>> write all this in match.pd.
>
> So what was the conclusion? Improving match.pd to be able to handle more cases
> like this se
Richard Biener wrote:
>
> Yeah ;) I'm currently bootstrapping/testing the patch that makes it possible
> to
> write all this in match.pd.
So what was the conclusion? Improving match.pd to be able to handle more cases
like this seems like a nice thing.
Wilco
Richard Biener wrote:
>
> Yeah ;) I'm currently bootstrapping/testing the patch that makes it possible
> to
> write all this in match.pd.
So did that pass bootstrap? It would be good to decide how to proceed with this.
Wilco
Jakub Jelinek wrote:
> On Wed, Apr 20, 2016 at 11:17:06AM +, Wilco Dijkstra wrote:
>> Can you quantify "don't like"? I benchmarked rawmemchr on a few targets
>> and it's slower than strlen, so it's hard to guess what you don't like about
>> it.
>
> This is the same stuff as has been discussed
On Wed, Apr 20, 2016 at 11:17:06AM +, Wilco Dijkstra wrote:
> Can you quantify "don't like"? I benchmarked rawmemchr on a few targets
> and it's slower than strlen, so it's hard to guess what you don't like about
> it.
This is the same stuff as has been discussed for mempcpy, rawmemchr is the
On Wed, Apr 20, 2016 at 1:56 PM, Wilco Dijkstra wrote:
> Richard Biener wrote:
>> Better - comments below. Jakub objections to the usefulness of the transform
>> remain - we do have the strlen pass that uses some global knowledge to decide
>> on profitability. One could argue that for -Os doing
Richard Biener wrote:
> Better - comments below. Jakub objections to the usefulness of the transform
> remain - we do have the strlen pass that uses some global knowledge to decide
> on profitability. One could argue that for -Os doing the reverse transform is
> profitable?
In what way would it
Jakub Jelinek wrote:
> I still don't like this transformation and would very much prefer to see
> using rawmemchr instead on targets that provide it, and also this is
> something that IMHO should be done in the tree-ssa-strlen.c pass together
> with the other optimizations in there. Similarly to s
On Wed, Apr 20, 2016 at 12:33 PM, Jakub Jelinek wrote:
> On Wed, Apr 20, 2016 at 11:44:08AM +0200, Richard Biener wrote:
>> (simplify
>> (BUILT_IN_STRCHR @0 integer_zerop)
>> (pointer_plus @0 (BUILT_IN_STRLEN:size_type_node @0)))
>
> I still don't like this transformation and would very much pre
On Wed, Apr 20, 2016 at 11:44:08AM +0200, Richard Biener wrote:
> (simplify
> (BUILT_IN_STRCHR @0 integer_zerop)
> (pointer_plus @0 (BUILT_IN_STRLEN:size_type_node @0)))
I still don't like this transformation and would very much prefer to see
using rawmemchr instead on targets that provide it, a
On Wed, Apr 20, 2016 at 10:45 AM, Richard Biener
wrote:
> On Tue, Apr 19, 2016 at 6:32 PM, Wilco Dijkstra
> wrote:
>> Richard Biener wrote:
>>>
>>> This folding should be added to gimple-fold.c:gimple_fold_builtin instead,
>>> the builtins.c foldings are purerly for folding to constants nowadays
On Tue, Apr 19, 2016 at 6:32 PM, Wilco Dijkstra wrote:
> Richard Biener wrote:
>>
>> This folding should be added to gimple-fold.c:gimple_fold_builtin instead,
>> the builtins.c foldings are purerly for folding to constants nowadays.
>
> So is this better? It's a lot more verbose for something so
Richard Biener wrote:
>
> This folding should be added to gimple-fold.c:gimple_fold_builtin instead,
> the builtins.c foldings are purerly for folding to constants nowadays.
So is this better? It's a lot more verbose for something so simple...
Unfortunately match.pd doesn't support this kind of th
On Mon, Apr 18, 2016 at 7:00 PM, Wilco Dijkstra wrote:
> Optimize strchr (s, 0) to s + strlen (s). strchr (s, 0) appears a common
> idiom for finding the end of a string, however it is not a very efficient
> way of doing so. Strlen is a much simpler operation which is significantly
> faster (eg.
On Mon, 2016-04-18 at 17:00 +, Wilco Dijkstra wrote:
> Optimize strchr (s, 0) to s + strlen (s). strchr (s, 0) appears a
> common
> idiom for finding the end of a string, however it is not a very
> efficient
> way of doing so. Strlen is a much simpler operation which is
> significantly
> fast
Jakub Jelinek wrote:
> On Mon, Apr 18, 2016 at 05:00:45PM +, Wilco Dijkstra wrote:
>> Optimize strchr (s, 0) to s + strlen (s). strchr (s, 0) appears a common
>> idiom for finding the end of a string, however it is not a very efficient
>> way of doing so. Strlen is a much simpler operation w
On Mon, Apr 18, 2016 at 05:00:45PM +, Wilco Dijkstra wrote:
> Optimize strchr (s, 0) to s + strlen (s). strchr (s, 0) appears a common
> idiom for finding the end of a string, however it is not a very efficient
> way of doing so. Strlen is a much simpler operation which is significantly
> fas
Optimize strchr (s, 0) to s + strlen (s). strchr (s, 0) appears a common
idiom for finding the end of a string, however it is not a very efficient
way of doing so. Strlen is a much simpler operation which is significantly
faster (eg. on x86 strlen is 50% faster for strings of 8 bytes and about
tw
37 matches
Mail list logo
