Extended Description

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}<%for.body3> to i64))'.

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}<%for.body3> to i64))' to an equal SCEVAddRecExpr '{{0,+, (8 *(sext i32 %ldc to i64)))}<%for.cond1.preheader>,+,8}<%for.body3>'.