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-patches@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. Regards, Kai
