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. Ciao, Michael.
