> -----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.
