[PATCH] [Polly][PoC] Approximate the parameters when creating runtime alias checks.

Tobias Grosser tobias at grosser.es
Wed Sep 24 08:16:40 PDT 2014


On 24/09/2014 16:32, Johannes Doerfert wrote:
>>> ! In D5441#4, @grosser wrote:
>> It seems you left out the code generation support, such that after this patch the test cases start to crash. This is probably intentional, but I would like to note this to avoid misunderstandings.
> Yes, I left out codegen and this was intentional :)
>
>> Regarding the patch, there are two questions that need to be checked:
>>
>> ### 1) Is it correct?
>>
>> For the following code:
>>
>> ```
>> void foo(float *A, float *B, long N, long p1) {
>>          for (long i = 0; i < 100; i++)
>>                  B[i] = A[i - p1];
>> }
>> ```
>>
>> I get the following exception:
>>
>> isl/isl_tab_pip.c:491: unbounded optimum
>>
>> Introducing a single new parameter that is smaller or larger than all parameters does not work in case you have negative coefficients for certain parameters.
> True, the min/max parameter should only be greater then all negative/positive ones respectively. If both are present we shouldn't relate the real parameter with the fake one and do not project it out.

I see. I am afraid it may become even more complicated in case 
existentially quantified dimensions are involved or parameters are only 
implicitly part of a constraint (e.g., by limiting outer loop 
dimensions, which again limit inner dimensions).


>> ### 2) What do we loose with this over-approximation?
>>
>> Do you know what kind of simple cases we would now refuse? Are those exceptional cases or pretty common ones?
> I don't but exactly.
>
>> My feeling is that we might loose some rather basic cases. To fix this, we could possibly try to detect them and then use this approximation. However, maybe just detecting the possibly complicated cases and blindly bailing out would already good enough for now.
> Bail seems more and more to be the option to choose.
>
>> I remember you recently used isl_set_involves_dims() in the "[Polly] Find all loops involved in now innermost ones." patch. Maybe we can use this one here to count the number of parameter dimensions involved in a certain access set and bail out if more than X parameters are involved?
> We could and we would need to check each the signs of parameter somehow. Only positive ones can be aproximated by Pmax and only negative ones by some Pmin for the maximum computation and the other way around for the minimum computation. If after approximation to many parameters remain we would need to bail again.

Why do we need to check each of the signs? As a first step, could we 
just bail out and not even try to approximate. Like this we could delay 
to reason about a good approximation strategy until we find a test case
where this approximation is actually needed to perform a useful 
optimization.

Tobias




More information about the llvm-commits mailing list