2011/10/6 Michael Matz <m...@suse.de>: > Hi, > > On Thu, 6 Oct 2011, Kai Tietz wrote: > >> > at which point this association doesn't make sense anymore, as >> >> Sorry, exactly this doesn't happen, due an ANDIF isn't simple, and >> therefore it isn't transformed into and AND. > > Right ... > >> > ((W AND X) AND Y) AND Z >> > >> > is just as fine. So, the reassociation looks fishy at best, better get >> > rid of it? (which of the testcases breaks without it?) >> >> None. I had this implemented first. But Richard was concerned about >> making non-IF conditions too long. I understand that point that it >> might not that good to always modify unconditionally to AND/OR chain. > > ... and I see that (that's why the transformation should be desirable for > some definition of desirable, which probably includes "and RHS not too > long chain"). As it stands right now your transformation seems to be a > fairly ad-hoc try at avoiding this problem. That's why I wonder why to do > the reassoc at all? Which testcases break _without_ the reassociation, > i.e. with only rewriting ANDIF -> AND at the outermost level?
I don't do here reassociation in inner. See that patch calls build2_loc, and not fold_build2_loc anymore. So it doesn't retries to associate in inner anymore (which might be something of interest for the issue Jakub mentioned). There is no test actual failing AFAICS. I just noticed size-differences by this. Nevertheless it might be better to enhance reassociation pass to break-up (and repropagate) GIMPLE_CONDs with non-side-effect, as Jakub suggested. The other chance might be here to allow deeper chains then two elements within one AND/OR element, but this would be architecture dependent. For x86 -as example- used instruction cycles for a common for branching would suggest that it might be profitable to have here 3 or 4 leafs within one AND|OR chain. But for sure on other architectures the amount of leafs varies. Regards, Kai
