Re: Please review writeup for fixing PR 78809 (inline strcmp for small constant strings)

[Qing Zhao <qing dot zhao at oracle dot com>]

>>>> 
>>>>   A would like to be put in gimple fold phase (in routine
>>>> "gimple_fold_builtin_string_compare" of gimple-fold.c
>> 
>>>> OK.  Note that various optimizations can expose N or one of the strings
>>> to be a constant.  So having it as part of the folders makes a lot of
>>> sense .
>> 
>> I have finished this part of change and sent the patch to gcc-patch
>> alias already. 
>> https://patchwork.ozlabs.org/patch/838200/
>> 
>> Do you think it’s necessary to add the same functionality at other
>> places, such as tree-ssa-strlen.c, in order to catch more cases?
> For "A"?  No, I think having it in the gimple folder is fine.  Most
> passes call into the folder when they make noteable changes to a
> statement.  So if a later pass exposes one argument as a string constant
> your code for "A" should get a chance to fold the call.

Okay. 
> 
>>> 
>>>>   B would like to be put in strlen phase (add new
>>>> "handle_builtin_str(n)cmp" routines in tree-ssa-strlen.c)
>>> Which is where you're most likely to have some kind of range information
>>> which ISTM you need to prove the non-constant string is large enough
>>> that you're not reading past its end.
>> Yes,that’s the main reason. another reason is: memcmp != 0 optimization
>> is implemented at -O2,  if we want to use this available work,
>> implement B at strlen phase is better.
> Noted.
> 
>> 
>>> 
>>>>   C would like to be put in expand phase (tree-ssa-strlen.c or
>>>> builtins.c): run-time performance testing is needed to decide the
>>>> predefined threshold T. 
>>> If you wanted to put it into expansion, I wouldn't object -- we could
>>> always do experiments to see if there's any value in moving it early
>>> (expansion to byte comparisons could possible expose other optimizations).
>> earlier to where? do you have any suggestion?  I can definitely do some
>> experiments. 
> The biggest question in my mind is what secondary opportunities arise
> when we expose the byte comparisons.  So things like if-conversion
> if-combination, propagation of equality, particularly in the single byte
> case, etc.

make sense to me.

> 
> The difficulty is tracking when exposure leads to these secondary
> opportunities.  I often end up looking for this kind of stuff by first
> identifying many source files where the transformation applies.  Then I
> generate dumps & assembly code for the transformation in each candidate
> location.  I first analyze the assembly files for differences.  If an
> assembly file shows a difference, then I look more closely to try and
> characterize the difference and if it looks interesting, then I work
> backwards to the dump files for more details.

usually, what kind of benchmarks or test cases are you recommending? 
I used to work a lot with SPEC, not sure whether that’s the same for working in GCC?

>>> 
>>> In general I like what you're suggesting.  And on a higher level I like
>>> that we're looking to rationalize where these kinds of things happen
>>> (compiler vs library).  It's something I've wanted to see happen for a
>>> long time.
>> Part of A and C has been implemented in glibc previously,  Wilco removed
>> them from Glibc  at
>>   https://sourceware.org/git/?p=glibc.git;a=commit;h=f7db120f67d853e0cfa2
> I know :-)  I loosely watch the glibc lists too and have expressed
> support for the glibc's team's effort to move transformations to the
> points where they make the most sense.

Yes, moving them to GCC makes good sense.

thanks.

Qing
> 
> jeff