On 04/06/15 20:57, Jakub Jelinek wrote:
> On Thu, Jun 04, 2015 at 06:36:33PM +0200, Ondřej Bílka wrote:
>> On Thu, Jun 04, 2015 at 04:01:50PM +0000, Joseph Myers wrote:
>>> On Thu, 4 Jun 2015, Richard Earnshaw wrote:
>>>
>>>>> Change that into
>>>>>
>>>>> int foo(char *s)
>>>>> {
>>>>> int l = strlen (s);
>>>>> char *p = memchr (s, 'a', l);
>>>>> return p+l;
>>>>> }
>
>> And Joseph you shouldn't restrict yourself only to values that are
>> present in variables to cover case where its implicit one from strcpy
>> converted to stpcpy.
>
> memchr isn't handled in that pass right now at all, of course it could be
> added, shouldn't be really hard. Feel free to file a PR and/or write
> a patch.
>
> As for e.g. the inlining of the first (or a few more) iterations of strcmp
> etc., that is certainly something that can be done in the compiler too and
> the compiler should have much better information whether to do it or not,
> as it shouldn't be done for -Os, or for basic blocks or functions predicted
> cold, because it enlarges the code size quite a lot.
You should also be wary of making the strings passed to the library
functions not naturally aligned. That can result in the code in the
library having to take a much slower path to regain any alignment done
by peeling the initial iteration(s). And if you're going to pass the
full string(s) anyway, then you'd better be pretty sure that doing the
check before the call is really likely to succeed.
R.
> For strcmp in particular, right now we handle the cast of two string
> literals at compile time, or e.g. strcmp (str, ""). For anything further,
> supposedly it should check if the target has inline expansion of strcmp
> (e.g. s390 or sh have them), then inlining one iteration is hardly
> beneficial.
>
> Jakub
>
