LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 19336 - Delinearization fails when loop indexes are in reverse order
Summary: Delinearization fails when loop indexes are in reverse order
Status: RESOLVED FIXED
Alias: None
Product: libraries
Classification: Unclassified
Component: Loop Optimizer (show other bugs)
Version: trunk
Hardware: PC Linux
: P normal
Assignee: Sebastian Pop
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-04 02:37 PDT by Tobias Grosser
Modified: 2014-09-10 03:28 PDT (History)
2 users (show)

See Also:
Fixed By Commit(s):


Attachments
Reduced test case (1.96 KB, application/octet-stream)
2014-04-04 02:37 PDT, Tobias Grosser
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Grosser 2014-04-04 02:37:22 PDT
Created attachment 12342 [details]
Reduced test case

We can sucessfully delinearize this piece of code:

A[][dim_size];

for (i = 0; i < n; i++)_
  for (j = 0; j < n; j++)
    A[i][j]

AddRec: {{%A,+,(4 * %dim_size)}<%loop.i>,+,4}<%loop.j>
Base offset: %A
ArrayDecl[UnknownSize][%dim_size] with elements of 4 bytes.
ArrayRef[{0,+,1}<%loop.i>][{0,+,1}<%loop.j>]

but fail for:

A[][dim_size];

for (i = 0; i < n; i++)_
  for (j = 0; j < n; j++)
    A[j][i]

AddRec: {{%A,+,4}<%loop.i>,+,(4 * %dim_size)}<%loop.j>
Base offset: %A
ArrayDecl[UnknownSize][1] with elements of 4 bytes.
ArrayRef[{0,+,1}<%loop.i>][{0,+,%dim_size}<%loop.j>]
Comment 1 Sebastian Pop 2014-04-04 12:12:24 PDT
I will fix this.
Comment 2 Sebastian Pop 2014-04-04 16:19:14 PDT
(In reply to comment #0)
> but fail for:
> 
> A[][dim_size];
> 
> for (i = 0; i < n; i++)_
>   for (j = 0; j < n; j++)
>     A[j][i]
> 
> AddRec: {{%A,+,4}<%loop.i>,+,(4 * %dim_size)}<%loop.j>
> Base offset: %A
> ArrayDecl[UnknownSize][1] with elements of 4 bytes.
> ArrayRef[{0,+,1}<%loop.i>][{0,+,%dim_size}<%loop.j>]

This is a correct delinearization, although it is not a very useful one:
- the size of the inner dimension is 1: ArrayDecl[UnknownSize][1]
- the stride of the inner dimension is parametric: [{0,+,%dim_size}<%loop.j>]

I think we should be able to modify SCEV->delinearize to "prefer" a non
parametric strides, and that would also solve the strange dimension size "1".
Comment 3 Tobias Grosser 2014-04-06 18:21:57 PDT
(In reply to comment #2)
> (In reply to comment #0)
> > but fail for:
> > 
> > A[][dim_size];
> > 
> > for (i = 0; i < n; i++)_
> >   for (j = 0; j < n; j++)
> >     A[j][i]
> > 
> > AddRec: {{%A,+,4}<%loop.i>,+,(4 * %dim_size)}<%loop.j>
> > Base offset: %A
> > ArrayDecl[UnknownSize][1] with elements of 4 bytes.
> > ArrayRef[{0,+,1}<%loop.i>][{0,+,%dim_size}<%loop.j>]
> 
> This is a correct delinearization, although it is not a very useful one:
> - the size of the inner dimension is 1: ArrayDecl[UnknownSize][1]
> - the stride of the inner dimension is parametric: [{0,+,%dim_size}<%loop.j>]
> 
> I think we should be able to modify SCEV->delinearize to "prefer" a non
> parametric strides, and that would also solve the strange dimension size "1".

Yes, non parametric strides should be preferred. With this stride, we can not really do a lot.

Tobi
Comment 4 Tobias Grosser 2014-09-10 03:28:56 PDT
I just tested with 217336 and this works. The corresponding test case is part of
Polly since 208233.