Here is another case which my tree combiner confuses the other tree optimizations but it should not.
I get in .vect: "not vectorized: number of iterations cannot be computed.".
If I change D1360 to be just n, it works.
If I change "n <= 1" to be "D1360 <= 0" It works (on the mainline without my tree combiner which is
the opposite of what my tree combiner does).
typedef float afloat __attribute__ ((__aligned__(16)));
main1 (int n , afloat * __restrict__ pa, afloat * __restrict__ pb)
int D1360 = n/2;
if (n <= 1) return 0;
ivtmp35 = 1;
ivtmp51 = ivtmp35;
pa[ivtmp51] = pb[ivtmp51];
ivtmp35 = ivtmp51 + 1;
} while (D1360 > ivtmp51);
This problem causes the following "regressions" with my tree combiner:
FAIL: gcc.dg/vect/vect-58.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-60.c scan-tree-dump-times vectorized 1 loops 1
These are real regressions because we are losing information.
In particular, when you replace D1360 <= 0 with n <= 1, we no longer can
determine that D1360 is <= 1.
This would require a pretty powerful assertion framework (when we learn
something about n, we'd have to know all expressions whose value depends on n,
which seems a bit much) to make up for.
I think for now we shouldn't combine before trying these transformations, or
limit combine until at least after loop, for things like conditionals whose
values have immediate uses in loop exit tests or something.
I was able to work around the problem which my tree combiner causes by doing what the old forward-
pro did which is only combine into a COND_EXPR if we used the SSA_NAME only once in the COND_EXPR
or when the resulting result is a constant (so we don't miss some optimizations).
suspend this one as this is hard and most likely not going to happen.