[PATCH][Middle-end]2nd patch of PR78809 and PR83026

[Qing Zhao]

Hi, Wilco,

thanks a lot for your review and comments.

> On Dec 15, 2017, at 6:41 AM, Wilco Dijkstra <Wilco.Dijkstra@arm.com> wrote:
> 
> Hi Qing,
> 
> Just looking at a very high level, I have a few comments:
> 
> 1. Constant folding str(n)cmp - folding is done separately in fold-const-call.c
>   and gimple-fold.c.  There is already code for folding strcmp and strncmp,
>   so we shouldn't need to add new foldings.  Or do you have an example that
>   isn't folded as expected? If so, a fix should be added to the existing code.

are you referring the following:

 B.1. (PR83026) When both arguments are constant strings and it's a strcmp:
    * if the length of the strings are NOT equal, we can safely fold the call
      to a non-zero value.
    * otherwise, do nothing now.


the following testing case cannot be folded by the current gimple-fold or fold-const-call:

int f1 (void)
{
  char *s0= "abcd";
  char s[8];
  strcpy (s, s0);
  return __builtin_strcmp(s, "abc") != 0;
}

in order to fold the above call, we need the strlen information that provided by the tree-ssa-strlen.c.
and I don’t think that improving the gimple-fold or fold-const-call can fold the above call to 1. 

with the strlen info in tree-ssa-strlen.c,  the strlen of s could be determined as 4, which is not equal
to the strlen of the constant string “abc”, then we can safely fold 

__builtin_strcmp(s, "abc") != 0

to 1. 

(actually, your above  comments remind me that one of my testcases added has some issue, I will fix the testcase,
strcmpopt_3.c). 

> 
> 2. Why check for str(n)cmp == 0 / != 0? There is no need to explicitly check
>   for equality comparisons since folding into memcmp is always good.

If the result is Not used to compare with 0, then we need the exact value of strcmp of two strings.  negative value, zero, or positive value.

I am not sure changing str(n)cmp to memcmp under such situation will still return the correct negative or positive value?

> 
> 3. Why handle strncmp? There is already code to convert strncmp into strcmp,
>   so why repeat that again in a different way? It just seems to make the
>   code significantly more complex for no benefit.

if strncmp cannot be convert to strcmp, there is still call to strncmp that we should handle, right? 

Qing


> 
> You can achieve the same effect by just optimizing strcmp into memcmp when
> legal without checking for equality comparison.  As a result you can considerably
> reduce the size of this patch while handling more useful cases.
> 
> Wilco
>