On Sat, Feb 15, 2014 at 12:15:22PM +0100, Ondřej Bílka wrote:
> On Sat, Feb 15, 2014 at 10:50:02AM +0100, Richard Biener wrote:
> > On Sat, Feb 15, 2014 at 10:45 AM, Prathamesh Kulkarni
> > <bilbotheelffri...@gmail.com> wrote:
> > > On Sat, Feb 15, 2014 at 2:28 PM, Jakub Jelinek <ja...@redhat.com> wrote:
> > >> On Sat, Feb 15, 2014 at 02:23:24PM +0530, Prathamesh Kulkarni wrote:
> > >>> This patch folds strchr (e, 0) to e + strlen (e), if e has no
> > >>> side-effects.
> > >>> Bootstrapped, regtested on x86_64-unknown-linux-gnu
> > >>> Ok for trunk ?
> > >>
> > >> Why do you think it is a good idea? It is often very much the opposite.
> > > I maybe completely wrong, but since strchr(p, 0), matches each
> > > character of p with c until '\0' is found, I thought it would be
> > > faster to call strlen, since strlen would just skip over characters upto
> > > '\0'.
> > > Also, I saw this committed in llvm trunk recently, and thought it
> > > might be a good idea:
> > > http://llvm-reviews.chandlerc.com/rL200736
> >
> > If it ends up being a good idea then please add this transform to
> > tree-ssa-strlen.c,
> > not to GENERIC builtins folding.
> >
> No, if that transform is good idea it should be added to headers. Also
> this will not match anything as with O1 and higher it already is
> transformed to rawmemchr(x, 0) as in program below.
>
> #include <string.h>
> char *
> foo (char *x)
> {
> return strchr (x, 0);
> }
Of course rawmemchr(x, 0) is much better implementation of strchr(x, 0) than
x + strlen(x). The reason why gcc doesn't transform it that way is because
rawmemchr is just a GNU extension, not part of C or POSIX.
Jakub
