Bug 18940 - Loop is not vectorized when it should be (VRP)
Summary: Loop is not vectorized when it should be (VRP)
Status: SUSPENDED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.0.0
: P2 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: missed-optimization
Depends on:
Blocks: vectorizer
  Show dependency treegraph
 
Reported: 2004-12-11 18:47 UTC by Andrew Pinski
Modified: 2016-08-27 22:42 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-12-21 03:55:56


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.