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 23426 - Polly can't delinearize some affine access due to type casting
Summary: Polly can't delinearize some affine access due to type casting
Status: RESOLVED FIXED
Alias: None
Product: Polly
Classification: Unclassified
Component: Optimizer (show other bugs)
Version: unspecified
Hardware: PC Linux
: P normal
Assignee: Xing
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-05 19:49 PDT by Xing
Modified: 2016-01-18 17:00 PST (History)
2 users (show)

See Also:
Fixed By Commit(s):


Attachments
matmul kernel Polly failed to detect SCOPs from (3.85 KB, application/octet-stream)
2015-05-05 19:49 PDT, Xing
Details
C source file of the matmul kernel (739 bytes, text/x-csrc)
2015-05-05 19:51 PDT, Xing
Details
Makefile to generate IR files and run the analysis (724 bytes, application/octet-stream)
2015-05-05 19:52 PDT, Xing
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Xing 2015-05-05 19:49:45 PDT
Created attachment 14288 [details]
matmul kernel Polly failed to detect SCOPs from

In the testcase attached a matmul kernel was given. The matrix dimension sizes are given in 32bit 'int' type.

When running SCOP detection on this kernel on a 64bit machine, Polly failed to detect the SCOP as expected because delinearization failed. In the first step of delinearization, Polly tries to collect parametric terms from all affine accesses and it expect every access is represented by a SCEVAddRecExpr. However, type casting (sign extending i32 to i64) may cause the access function to matrix C to be another kind of SCEV instead of SCEVAddRecExpr. For instance, running analysis on the given testcase, an SCEVMulExpr access function appears as '(8 * (sext i32 {{%ldc,+,%ldc}<%for.cond1.preheader>,+,1}<nw><%for.body3> to i64))<nsw>'.

To fix this, Hoisting all sext to the leaves (SCEVUnknowns) of the SCEV 
expression may indeed be a good strategy (basically using a uniform 
maximal type for the expression) may indeed be a good strategy. Some 'canonicalization' may be done to each access function before delinearization, turning '(8 * (sext i32 {{0,+,%ldc}<%for.cond1.preheader>,+,1}<nw><%for.body3> to i64))<nsw>' to an equal SCEVAddRecExpr '{{0,+, (8 *(sext i32 %ldc to i64)))<nsw>}<%for.cond1.preheader>,+,8}<nw><%for.body3>'.
Comment 1 Xing 2015-05-05 19:51:06 PDT
Created attachment 14289 [details]
C source file of the matmul kernel
Comment 2 Xing 2015-05-05 19:52:02 PDT
Created attachment 14290 [details]
Makefile to generate IR files and run the analysis
Comment 3 Tobias Grosser 2015-06-18 11:11:09 PDT
This was fixed in r238643 by adding the indvar pass to the canonicalization sequence.
Comment 4 Tanya Lattner 2016-01-18 17:00:27 PST
Move to Polly Product.