Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs

[Kai Tietz <ktietz70 at googlemail dot com>]

2011/10/27 Jiangning Liu <jiangning.liu@arm.com>:
>
>
>> -----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.

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