This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs
> -----Original Message-----
> From: Michael Matz [mailto:matz@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.