This is an archive of the discontinued LLVM Phabricator instance.

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

Authored by jdoerfert on Sep 22 2014, 10:10 AM.

Details

Reviewers
grosser

Diff Detail

Event Timeline

jdoerfert updated this revision to Diff 13940.Sep 22 2014, 10:10 AM
jdoerfert retitled this revision from to [Polly][PoC] Approximate the parameters when creating runtime alias checks..
jdoerfert updated this object.
jdoerfert edited the test plan for this revision. (Show Details)
jdoerfert added a reviewer: grosser.
jdoerfert added subscribers: Restricted Project, Unknown Object (MLST).
grosser edited edge metadata.Sep 24 2014, 6:55 AM

Hi Johannes,

thanks for your proof of concept.

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.

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.

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?

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.

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?

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.

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.

jdoerfert abandoned this revision.Sep 26 2014, 3:49 AM

Postponed until we find a usecase and a good heuristic.