Richard Biener <rguent...@suse.de> writes: > On Tue, 1 Mar 2022, Jiufu Guo wrote: > >> Segher Boessenkool <seg...@kernel.crashing.org> writes: >> >> > On Thu, Feb 24, 2022 at 09:50:28AM +0100, Richard Biener wrote: >> >> On Thu, 24 Feb 2022, Jiufu Guo wrote: >> >> > And another thing as Segher pointed out, CSE is doing too >> >> > much work. It may be ok to separate the constant handling >> >> > logic from CSE. >> >> >> >> Not sure - CSE just is value numbering, I don't see that it does >> >> more than that. Yes, it might have developed "heuristics" over >> >> the years what to CSE and to what and where to substitute and >> >> where not. But in the end it does just value numbering. >> > >> > It also does various micro-optimisations, like all the CC things it >> > does. >> > >> > It is not very good at doing the CSE job, but it cannot easily be >> > replaced by a better implementation because it does many other small >> > optimisations (that are not done elsewhere). >> > >> >> Thanks a lot for these comments! I'm also wondering if we would >> rewrite this cse.cc or refactor it in some aspects. > > I think time is better spent elsewhere ... I don't think CSE is as > bad as Segher depicts it - it might do "CC things" and other bits > but in the end that's going to be instruction/expression combination > things that "fit" likely because a value lattice (or just nonzero bits > in the cselib variant) existed. > > So what might be interesting would be to work towards cleansing > CSE of those, producing testcases and making sure a better fit > pass (combine? fwprop? compare-elim?) performs the desired > optimization. Hi Richard,
I'm not sure. I guess, those micro-optimizations may be also the the things which could be move to other pass, like fwprop/combining... Segher would correct me. :-) cse.cc contains the code to take care of constant/ const_anchors, expr folding, condition code/jump... BR, Jiufu > > But I'm not really sure what Segher is talking about - I suppose > it must be magic done inside cselib (which only does analysis), > not in cse.cc itself. > > Richard. > >> BR, >> Jiufu >> >> > >> > Segher >>
