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
2011/10/26 Michael Matz <matz@suse.de>:
> Hi,
>
> On Wed, 26 Oct 2011, Kai Tietz wrote:
>
>> > Yes, this part introduced different behavior for this small case,
>> >
>> > int f(char *i, int j)
>> > {
>> > ? ? ? ?if (*i && j!=2)
>> > ? ? ? ? ? ? ? ?return *i;
>> > ? ? ? ?else
>> > ? ? ? ? ? ? ? ?return j;
>> > }
>>
>> Well, as far as I understand C specification and sequence points, it
>> makes indeed a difference to do branch-cost optimization on instructions
>> might cause a signal traps. As signal could be handled in specifc
>> handlers. You need to consider here that short-circuit optimization
>> assumes associative law on operands. ?So right-hand side might be
>> evaluaded before the left-hand-side. ?And this indeed breaks IMHO the
>> sequences as mentioned in C specification about conditions.
>
> I'm not sure in this specific case. ?If it had been:
>
> if (*a && *b) ...
>
> the you'd be right. ?The side-effect of dereferencing a must happen before
> *b, and hence transforming this into (*a!=0)&(*b!=0) would be wrong. ?But
> in the case at hand we only have one potentially problematic (aka
> detectable) side-effect (*i), so I don't think you could construct a
> program that detects the difference. ?It would entail detecting that
> "j!=2" was already evaluated, when (say) the segfault happens, but you
> can't as the variable is non-volatile. ?It also can't happen that the
> side-effect *i does not occur (which also would be a problem). ?So, I
> think there wasn't an actual problem before, and it had fewer jumps.
>
>
> Ciao,
> Michael.
the case can be produced quite easily.
Eg:
extern int global = 0;
....
if (*a && global) ...
...
the issue is that by C-specification see here 5.1.2.2.3 about
program-termination.The important point is here::
Evaluation of an expression may produce side effects. At certain
specified points in the execution sequence called sequence points, all
side effects of previous evaluations shall be complete *** and no side
effects of subsequent evaluations shall have taken place ***
Annex C describes sequence-points as
1 The following are the sequence points described in 5.1.2.3:
— The call to a function, after the arguments have been evaluated (6.5.2.2).
— The end of the first operand of the following operators: logical AND
&& (6.5.13); logical OR || (6.5.14); conditional ? (6.5.15); comma ,
(6.5.17).
...
Regards,
Kai