[LLVMdev] [Polly] Analysis of the expensive compile-time overhead of Polly Dependence pass
tobias at grosser.es
Wed Jul 31 08:10:23 PDT 2013
On 07/30/2013 09:13 PM, Star Tan wrote:
> Hi Tobias and Sven,
> Thanks for your discussion and suggestion.>
> @Tobias and Polly developers:
> I have attached a patch file to fix this problem. The key idea is to
> keep ISL library always seeing the same single parameter for those
> memory accesses that use the same index variables even though they have
> different constant base values.
[.. Very nice improvements .. ]
>>This is obviously a hack. The base is not always a constant.
>>You can probably just call use something like,
>>isl_pw_aff *BaseValue = visit(AR->getOperand(0))
>>Affine = isl_pw_aff_sum(Affine, BaseValue);
> Currently, I only handle constant base values because I have not found a
> good way to handle general base values. isl_pw_aff_add requires two
> isl_pw_aff parameters, but Affine is actually of isl_aff type. Perhaps
> we could first commit a patch file to handle common cases, then we can
> considering submitting another patch file to handle general cases.
No, we should get this right from the start (and also add test cases).
isl provides a function to create an isl_pw_aff from a isl_aff. You can
just use that.
>>I think this is the right idea, but probably the wrong place to put it.
>>I would put this into SCEVValidator::visitAddRecExpr. This function
>>always adds the AddRecExpr itself as a parameter, whenever it is found
>>to be parametric. However, what we should do is to create a new ScevExpr
>>that starts at zero and is otherwise identical. We then add this as a
>>parameter. When doing this, we now also need to keep all the parameters
>>that have been found previously in the base expression.
> A lot of Polly functions access ParameterIds and Parameters using existing ScevExpr. If we create new ScevExpr and put them into Parameters and ParameterIds, it may require some extra tricks to handle the mapping from existing ScevExpr to newly created ScevExpr. I think we can consider fixing it later.
Mh, I would think similar tricks are needed to perform your parameter
remapping. I would prefer we think this through now and then choose a
solution that works for us.
More information about the llvm-dev