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. 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 > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Ivo Totev; HRB 36809 (AG Nuernberg)
