https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #47 from qinzhao at gcc dot gnu.org ---
all the issues triggered by the previous patch have been fixed.
I am planing to close this PR as fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #46 from qinzhao at gcc dot gnu.org ---
https://gcc.gnu.org/viewcvs/gcc?view=revision=263028
was to fix the optimization level issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|8.2 |8.3
--- Comment #45 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #44 from Qing Zhao ---
> (In reply to wilco from comment #43)
will provide a simple patch for this issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #43 from Wilco ---
(In reply to qinzhao from comment #42)
> just checked in the patch for fixing the unsigned char issue as:
> https://gcc.gnu.org/viewcvs/gcc?view=revision=262907
That looks it is using unsigned char accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #42 from qinzhao at gcc dot gnu.org ---
just checked in the patch for fixing the unsigned char issue as:
https://gcc.gnu.org/viewcvs/gcc?view=revision=262907
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #41 from Qing Zhao ---
> --- Comment #40 from Wilco ---
> See eg. http://www.iso-9899.info/n1570.html section 7.24.4:
>
> "The sign of a nonzero value returned by the comparison functions memcmp,
> strcmp, and strncmp is determined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #40 from Wilco ---
(In reply to Qing Zhao from comment #39)
> > --- Comment #38 from Wilco ---
> > This uses signed char while the C standard says the comparison is done on
> > unsigned chars.
> >
>
> during my implementation, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #39 from Qing Zhao ---
> --- Comment #38 from Wilco ---
> This uses signed char while the C standard says the comparison is done on
> unsigned chars.
>
during my implementation, I did some research on whether I should use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #38 from Wilco ---
(In reply to qinzhao from comment #37)
> since all the implementation were in trunk.
> can I close this PR now?
Thanks, it generates pretty much what I expected for t1.
However there is an issue:
t1:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #37 from qinzhao at gcc dot gnu.org ---
since all the implementation were in trunk.
can I close this PR now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #36 from qinzhao at gcc dot gnu.org ---
the 3rd part (the last part) of this PR was checked into GCC 9 today as:
https://gcc.gnu.org/viewcvs/gcc?view=revision=262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||qinzhao at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|8.0 |8.2
--- Comment #34 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #33 from Qing Zhao ---
with SPEC2017 on X86, I didn't see any run-time performance change as expected.
due to the date I collected for code size change, looks like that n=3 or n=4
might be a reasonable default. n=3 might be safer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #32 from Qing Zhao ---
Created attachment 43298
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43298=edit
code size impact from inlining str(n)cmp with different n on X86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #31 from Wilco ---
(In reply to Qing Zhao from comment #30)
> (in reply to Wilco from comment #29)
> >
> > The new test is better, however it uses i % 15 which means an expensive
> > division by constant every loop iteration. It's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #30 from Qing Zhao ---
(in reply to Wilco from comment #29)
>
> The new test is better, however it uses i % 15 which means an expensive
> division by constant every loop iteration. It's best to change to i & 15. Also
> using an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #29 from Wilco ---
(In reply to Qing Zhao from comment #28)
> >
> > I don't think this is a good test. Repeatedly calling strcmp with the same
> > inputs is not something real code does, especially when the string matches
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #28 from Qing Zhao ---
>
> I don't think this is a good test. Repeatedly calling strcmp with the same
> inputs is not something real code does, especially when the string matches
> exactly. Why would it do that? The consequence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #27 from Richard Earnshaw ---
(In reply to Qing Zhao from comment #23)
> qinzhao@gcc116:~/Bugs/78809/const_cmp$ cat t_p.c
> #include
>
> char array[]= "fishi";
>
> #define NUM 10
> int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
Qing Zhao changed:
What|Removed |Added
Attachment #42449|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #25 from Wilco ---
(In reply to Qing Zhao from comment #24)
> From the above, we can see:
> even with n is as big as 20, inlined version is much faster than the
> non-inlined version, both on aarch64 (no hardware string compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #24 from Qing Zhao ---
From the above, we can see:
even with n is as big as 20, inlined version is much faster than the
non-inlined version, both on aarch64 (no hardware string compare insn provided)
and X86 (hardware string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #23 from Qing Zhao ---
I have an implementation for the part C of this task in my private space:
part C: for strcmp (s1, s2), strncmp (s1, s2, n):
if the result is NOT used to do simple equality test against zero, one of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #22 from Qing Zhao ---
https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00962.html
2nd patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #21 from Jeffrey A. Law ---
Author: law
Date: Fri Nov 17 05:32:05 2017
New Revision: 254856
URL: https://gcc.gnu.org/viewcvs?rev=254856=gcc=rev
Log:
2017-11-15 Qing Zhao
PR middle-end/78809
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #20 from Qing Zhao ---
design doc is at:
https://www.mail-archive.com/gcc@gcc.gnu.org/msg83822.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #18 from Wilco ---
(In reply to Qing Zhao from comment #17)
> (In reply to Wilco from comment #16)
>
> >> const char s[8] = “abcd\0abc”; // null byte in the middle of the string
> >> int f2(void) { return __builtin_strcmp(s, "abc")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #17 from Qing Zhao ---
(In reply to Wilco from comment #16)
>> const char s[8] = “abcd\0abc”; // null byte in the middle of the string
>> int f2(void) { return __builtin_strcmp(s, "abc") != 0; }
>> int f3(void) { return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #16 from Wilco ---
(In reply to Qing Zhao from comment #15)
> (In reply to Wilco from comment 14)
> > The only reason we have to do a character by character comparison is
> > because we
> > cannot read beyond the end of a string.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #15 from Qing Zhao ---
(In reply to Wilco from comment 14)
> The only reason we have to do a character by character comparison is because
> we
> cannot read beyond the end of a string. However when we know the size or
> alignment we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #14 from Wilco ---
(In reply to Qing Zhao from comment #11)
> (In reply to Wilco from comment #9)
>
> > str(n)cmp with a constant string can be changed into memcmp if the string
> > has a
> > known alignment or is an array of known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #13 from Qing Zhao ---
(In reply to Richard Earnshaw from comment 12)
> That's not entirely correct. Notionally memcmp needs to return a value
> representing the relative difference of the first different byte in the
> compared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #12 from Richard Earnshaw ---
(In reply to Qing Zhao from comment #7)
> on the other hand, memcmp will NOT early stop, it will compare exactly N
> bytes of both buffers. As a result, the compiler can compare multiple bytes
> at one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #11 from Qing Zhao ---
(In reply to Wilco from comment #9)
> str(n)cmp with a constant string can be changed into memcmp if the string has
> a
> known alignment or is an array of known size. We should check the common cases
> are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #10 from Qing Zhao ---
>> From the data, we can see the inlined version of strcmp (by glibc) is much
>> slower than the direct call to strcmp. (this is for size 2)
>> I am using GCC farm machine gcc116:
>
> This result doesn't make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #9 from Wilco ---
(In reply to Qing Zhao from comment #7)
str(n)cmp with a constant string can be changed into memcmp if the string has a
known alignment or is an array of known size. We should check the common cases
are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #8 from Wilco ---
> /home/qinzhao/Install/latest/bin/gcc -O2 t_p_1.c t_p.c
> non-inlined version
> 20.84user 0.00system 0:20.83elapsed 100%CPU (0avgtext+0avgdata
> 360maxresident)k
> 0inputs+0outputs (0major+135minor)pagefaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #7 from Qing Zhao ---
I have studied the inlining of memcmp and str(n)cmp in GCC, the following are a
summary of my study so far:
1. memcmp is different from str(n)cmp as the following:
• strcmp compares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #6 from Qing Zhao ---
(A correction to comment 4:
when adding #include , the call to strcmp(s, "a") was inlined by
glibc in the header
with the latest upstream GCC
)
with attached testing case, on GCC farm machine gcc116, I got
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #5 from Qing Zhao ---
Created attachment 42449
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42449=edit
Run time performance testing case on aarch64
this is for testing the run-time performance of inlined version of strcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
Wilco changed:
What|Removed |Added
CC||wdijkstr at arm dot com
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
Qing Zhao changed:
What|Removed |Added
CC||qing.zhao at oracle dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #2 from wilco at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> We may have dups of this. And we now have inlining for strcmp/memcmp when
> the
> result is only compared against zero.
I don't see that happening
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1
48 matches
Mail list logo