> -----Original Message----- > From: Kai Tietz [mailto:ktiet...@googlemail.com] > Sent: Thursday, October 27, 2011 5:36 PM > To: Jiangning Liu > Cc: Michael Matz; Richard Guenther; Kai Tietz; gcc-patches@gcc.gnu.org; > Richard Henderson > Subject: Re: [patch tree-optimization]: Improve handling of > conditional-branches on targets with high branch costs > > 2011/10/27 Jiangning Liu <jiangning....@arm.com>: > > > > > >> -----Original Message----- > >> From: Michael Matz [mailto:m...@suse.de] > >> Sent: Wednesday, October 26, 2011 11:47 PM > >> To: Kai Tietz > >> Cc: Jiangning Liu; Richard Guenther; Kai Tietz; gcc- > patc...@gcc.gnu.org; > >> Richard Henderson > >> Subject: Re: [patch tree-optimization]: Improve handling of > >> conditional-branches on targets with high branch costs > >> > >> Hi, > >> > >> On Wed, 26 Oct 2011, Kai Tietz wrote: > >> > >> > So you would mean that memory dereferencing shouldn't be > considered > >> as > >> > side-effect at all? > >> > >> No. I haven't said this at all. Of course it's a side-effect, but > >> we're > >> allowed to remove existing ones (under some circumstances). We're > not > >> allowed to introduce new ones, which means that this ... > >> > >> > So we would happily cause by code 'if (i && *i != 0) an crash, as > >> > memory-dereference has for you no side-effect? > >> > >> ... is not allowed. But in the original example the memread was on > the > >> left side, hence occured always, therefore we can move it to the > right > >> side, even though it might occur less often. > >> > >> > In you special case it might be valid that, if first (and C-fold- > >> const > >> > doesn't know if the side-effect condition is really the first, as > it > >> > might be a sub-sequence of a condition) condition might trap or > not, > >> to > >> > combine it. But branching has to cover the general cases. If you > >> find > >> > a way to determine that left-hand operand in fold_const's > branching > >> code > >> > is really the left-most condition in chain, then we can add such a > >> > special case, but I don't see here an easy way to determine it. > >> > >> Hmm? I don't see why it's necessary to check if it's the left-most > >> condition in a chain. If the left hand of '&&' is a memread it can > >> always > >> be moved to the right side (or the operator transformed into '&' > which > >> can > >> have the same effect), of course only if the original rhs is free of > >> side > >> effects, but then independed if the && was part of a larger > expression. > >> The memread will possibly be done fewer times than originally, but > as > >> said, that's okay. > >> > > > > Agree. The point is for the small case I gave RHS doesn't have side > effect > > at all, so the optimization of changing it to AND doesn't violate C > > specification. We need to recover something for this case, although > it did > > improve a lot for some particular benchmarks. > > > > Thanks, > > -Jiangning > > > >> > >> Ciao, > >> Michael. > > Hmm, so we can allow merging to AND, if the left-hand-side might trap > but has no-side-effects and rhs has neither trapping nor side-effects. > As for the case that left-hand side has side-effects but right-hand > not, we aren't allowed to do this AND/OR merge. For example 'if ((f = > foo ()) != 0 && f < 24)' we aren't allowed to make this > transformation. > > This shouldn't be that hard. We need to provide to simple_operand_p_2 > an additional argument for checking trapping or not. >
Would it be OK if I file a tracker in bugzilla against this? > Regards, > Kai
