This is the mail archive of the
mailing list for the GCC project.
Re: Exploiting knowing sizes of string.
- From: Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>, Jakub Jelinek <jakub at redhat dot com>
- Cc: Joseph Myers <joseph at codesourcery dot com>, gcc at gcc dot gnu dot org, law at redhat dot org
- Date: Thu, 04 Jun 2015 16:57:49 +0100
- Subject: Re: Exploiting knowing sizes of string.
- Authentication-results: sourceware.org; auth=none
- References: <20150604105929 dot GA19141 at domone> <alpine dot DEB dot 2 dot 10 dot 1506041206200 dot 31862 at digraph dot polyomino dot org dot uk> <20150604123319 dot GF10247 at tucnak dot redhat dot com> <20150604125331 dot GA22076 at domone> <20150604125920 dot GG10247 at tucnak dot redhat dot com> <20150604142304 dot GA23875 at domone>
On 04/06/15 15:23, OndÅej BÃlka wrote:
> On Thu, Jun 04, 2015 at 02:59:20PM +0200, Jakub Jelinek wrote:
>> On Thu, Jun 04, 2015 at 02:53:31PM +0200, OndÅej BÃlka wrote:
>>> On Thu, Jun 04, 2015 at 02:33:19PM +0200, Jakub Jelinek wrote:
>>>> On Thu, Jun 04, 2015 at 12:26:03PM +0000, Joseph Myers wrote:
>>>>>> Again is this worth a gcc pass?
>>>>> This isn't a matter of compiler passes; it's additional checks in existing
>>>>> built-in function handling. Maybe that built-in function handling should
>>>>> move to the match-and-simplify infrastructure (some, for libm functions
>>>>> and bswap, already has) to make this even simpler to implement.
>>>> GCC already has a pass that attempts to track known and earlier computed
>>>> lengths of strings, and do various transformations and optimizations based
>>>> on that, see the tree-ssa-strlen.c pass. Most of that you really can't do
>>>> at the glibc headers level.
>>> Yes, I was writing down ideas that I have and this was one of these. I
>>> didn't knew it does transformations, just checked that it doesn't use
>>> length from stpcpy or in
>> It does use length from stpcpy in various cases, but stpcpy needs to be
>> prototyped. See gcc/testsuite/gcc.dg/strlenopt* for what it does.
>>> int foo(char *s)
>>> int l = strlen (s);
>>> char *p = strchr (s,'a');
>>> return p+l;
>> And what do you want to optimize here? The length from strlen is different
>> from the difference between p and s. Furthermore, p can return NULL.
> Change that into
> int foo(char *s)
> int l = strlen (s);
> char *p = memchr (s, 'a', l);
> return p+l;
Which is still meaningless if 'a' does not appear in s => when the
result is NULL + l.
In fact, unless 'a' is the first character the result is possibly
meaningless anyway, since you can't know that p+l doesn't point more
than one beyond the end of the object.
Perhaps you just meant to return 'p'?