> On Jun 22, 2018, at 11:49 PM, Jeff Law <l...@redhat.com> wrote: > > On 05/29/2018 06:08 PM, Qing Zhao wrote: >> Hi, Jeff, >> >> Thanks a lot for your review and comments. >> >> I have updated my patch based on your suggestion, and retested this whole >> patch on both X86 and aarch64. >> >> please take a look at the patch again. >> >> thanks. >> >> Qing >> >>> On May 25, 2018, at 3:38 PM, Jeff Law <l...@redhat.com> wrote: >>> So I originally thought you had the core logic wrong in the immediate >>> uses loop. But it's actually the case that the return value is the >>> exact opposite of what I expected. >>> >>> ie, I expected "TRUE" to mean the call was transformed, "FALSE" if it >>> was not transformed. >>> >>> Can you fix that so it's not so confusing? >>> >>> I think with that change we'll be good to go, but please repost for a >>> final looksie. >>> >>> THanks, >>> Jeff >> >> >> 0001-2nd-Patch-for-PR78009.patch >> >> >> From 750f44ee0777d55b568f07e263babdedd532d315 Mon Sep 17 00:00:00 2001 >> From: qing zhao <qing.z...@oracle.com <mailto:qing.z...@oracle.com>> >> Date: Tue, 29 May 2018 16:15:21 -0400 >> Subject: [PATCH] 2nd Patch for PR78009 Patch for PR83026 >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 >> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809> >> Inline strcmp with small constant strings >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83026 >> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83026> >> missing strlen optimization for strcmp of unequal strings >> >> The design doc for PR78809 is at: >> https://www.mail-archive.com/gcc@gcc.gnu.org/msg83822.html >> <https://www.mail-archive.com/gcc@gcc.gnu.org/msg83822.html> >> >> this patch is for the second part of change of PR78809 and PR83026: >> >> B. for strncmp (s1, s2, n) (!)= 0 or strcmp (s1, s2) (!)= 0 >> >> B.1. (PR83026) When the lengths of both arguments are constant and >> it's a strcmp: >> * if the lengths are NOT equal, we can safely fold the call >> to a non-zero value. >> * otherwise, do nothing now. >> >> B.2. (PR78809) When the length of one argument is constant, try to replace >> the call with a __builtin_str(n)cmp_eq call where possible, i.e: >> >> strncmp (s, STR, C) (!)= 0 in which, s is a pointer to a string, STR is a >> string with constant length, C is a constant. >> if (C <= strlen(STR) && sizeof_array(s) > C) >> { >> replace this call with >> __builtin_strncmp_eq (s, STR, C) (!)= 0 >> } >> if (C > strlen(STR) >> { >> it can be safely treated as a call to strcmp (s, STR) (!)= 0 >> can handled by the following strcmp. >> } >> >> strcmp (s, STR) (!)= 0 in which, s is a pointer to a string, STR is a >> string with constant length. >> if (sizeof_array(s) > strlen(STR)) >> { >> replace this call with >> __builtin_strcmp_eq (s, STR, strlen(STR)+1) (!)= 0 >> } >> >> later when expanding the new __builtin_str(n)cmp_eq calls, first expand >> them >> as __builtin_memcmp_eq, if the expansion does not succeed, change them back >> to call to __builtin_str(n)cmp. >> >> adding test case strcmpopt_2.c and strcmpopt_4.c into gcc.dg for part B of >> PR78809 adding test case strcmpopt_3.c into gcc.dg for PR83026 >> >> bootstraped and tested on both X86 and Aarch64. no regression. >> --- >> gcc/builtins.c | 33 ++++ >> gcc/builtins.def | 5 + >> gcc/gimple-fold.c | 5 + >> gcc/testsuite/gcc.dg/strcmpopt_2.c | 67 ++++++++ >> gcc/testsuite/gcc.dg/strcmpopt_3.c | 31 ++++ >> gcc/testsuite/gcc.dg/strcmpopt_4.c | 16 ++ >> gcc/tree-ssa-strlen.c | 304 >> ++++++++++++++++++++++++++++++++++--- >> gcc/tree-ssa-structalias.c | 2 + >> gcc/tree.c | 8 + >> 9 files changed, 454 insertions(+), 17 deletions(-) >> create mode 100644 gcc/testsuite/gcc.dg/strcmpopt_2.c >> create mode 100644 gcc/testsuite/gcc.dg/strcmpopt_3.c >> create mode 100644 gcc/testsuite/gcc.dg/strcmpopt_4.c > Sorry for the long delay. This needs a ChangeLog. With the ChangeLog > it is OK for the trunk.
Hi, Jeff, the patch had been committed with ChangeLogs as following: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=261039 <https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=261039> thanks. Qing > > Jeff
