Bug 18940

Summary: Loop is not vectorized when it should be (VRP)
Product: gcc Reporter: Andrew Pinski <pinskia>
Component: tree-optimizationAssignee: Not yet assigned to anyone <unassigned>
Status: SUSPENDED ---    
Severity: enhancement CC: gcc-bugs
Priority: P2 Keywords: missed-optimization
Version: 4.0.0   
Target Milestone: ---   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed: 2005-12-21 03:55:56
Bug Depends on:    
Bug Blocks: 53947    

Description Andrew Pinski 2004-12-11 18:47:42 UTC
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)));
int
main1 (int n , afloat * __restrict__ pa, afloat * __restrict__ pb)
{
  int i;
  int ivtmp51;
  int ivtmp35;
  int D1360 = n/2;
  
  if (n <= 1) return 0;
  
  ivtmp35 = 1;

  do {
    ivtmp51 = ivtmp35;
    pa[ivtmp51] = pb[ivtmp51];
    ivtmp35 = ivtmp51 + 1;
  }  while (D1360 > ivtmp51);
  
  return 0;
}
Comment 1 Andrew Pinski 2004-12-11 18:52:34 UTC
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
Comment 2 Daniel Berlin 2004-12-12 04:59:58 UTC
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.

Comment 3 Andrew Pinski 2004-12-22 07:38:34 UTC
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).
Comment 4 Andrew Pinski 2005-03-23 03:08:49 UTC
suspend this one as this is hard and most likely not going to happen.