>>>> >>>> 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
