On 08/26/2015 11:29 PM, Ajit Kumar Agarwal wrote:
Thanks. The following testcase testsuite/gcc.dg/tree-ssa/ifc-5.c
void dct_unquantize_h263_inter_c (short *block, int n, int qscale,
int nCoeffs) { int i, level, qmul, qadd;
qadd = (qscale - 1) | 1; qmul = qscale << 1;
for (i = 0; i <= nCoeffs; i++) { level = block[i]; if (level < 0)
level = level * qmul - qadd; else level = level * qmul + qadd;
block[i] = level; } }
The above Loop is a candidate of path splitting as the IF block
merges at the latch of the Loop and the path splitting duplicates The
latch of the loop which is the statement block[i] = level into the
predecessors THEN and ELSE block.
Due to above path splitting, the IF conversion is disabled and the
above IF-THEN-ELSE is not IF-converted and the test case fails.
So I think the question then becomes which of the two styles generally
results in better code? The path-split version or the older
if-converted version.
If the latter, then this may suggest that we've got the path splitting
code at the wrong stage in the optimizer pipeline or that we need better
heuristics for when to avoid applying path splitting.
There were following review comments from the above patch.
+/* This function performs the feasibility tests for path splitting
+ to perform. Return false if the feasibility for path splitting
+ is not done and returns true if the feasibility for path
splitting + is done. Following feasibility tests are performed.
+ + 1. Return false if the join block has rhs casting for assign
+ gimple statements.
Comments from Jeff:
These seem totally arbitrary. What's the reason behind each of
these restrictions? None should be a correctness requirement
AFAICT.
In the above patch I have made a check given in point 1. in the loop
latch and the Path splitting is disabled and the IF-conversion
happens and the test case passes.
That sounds more like a work-around/hack. There's nothing inherent with
a type conversion that should disable path splitting.
What happens if we delay path splitting to a point after if-conversion
is complete?
Alternately, could if-conversion export a routine which indicates if a
particular sub-graph is likely to be if-convertable? The path splitting
pass could then use that routine to help determine if the path ought to
be split or if it should instead rely on if-conversion.
Jeff
