[LLVMdev] [GSoC] Increase the coverage of Polly

[Tobias Grosser]

On 04/04/2011 12:23 AM, Vlad Krylov wrote:
>
> Hi.

Hi Vlad,

first of all it seems the conflict with raghesh was already solved. Nice.

Regarding your draft. It looks like a reasonable first version, but it 
obviously needs to be extended for the final application. I would also 
recommend to install Polly and try to find the first test cases that 
cannot be handled.

Some comments to your work plan:

> My plan would be:
>
> 1w Study sources of Polly and LLVM docs relating to analysis
You should do this for your application. ;-) At least you should start. 
Did you already find the place in the scopdetection where we check if an 
access function is valid?

> 2w Create tests which demonstrate problems with NSW/NUW
I think it would be good to show at least one test case already in the 
application.

> 3-4w Fix the handling of wrap overflows.
What does need to be fixed? What is wrong at the moment? (there is 
obviously a problem as stated on the Polly wiki, but I believe it would 
be good to explain this to the audience. It will also be good for you to 
understand the actual problem in the code (In case you need help feel 
free to ask)).

> 5w Complete middle term paperwork.
What is middle term paperwork?

> 6w Create tests for each of cases which are not currently optimized
> (e.g. have min/max, sext/zext, trunc or unsigned comparisons in the loop
> bounds or memory accesses).
Again. Some test cases could already be shown in the application.

> 7w Learn how optimization process work for this examples.
I do not think you need to optimize here anything. It should be 
sufficient to recognize code that includes such statements and transform 
them into a polyhedral represenation. Optimizers like Pluto will 
automatically calculate the relevant optimizations, if you generate a 
correct polyhedral representation.

> 8-10w Enable tests one by one.
By 'Enable tests' do you mean implementing support for min/max .. 
expressions?

> 11w Estimate SPEC 264ref performnace improvement (yes, I have access to
> one).
What do you plan to measure exactly? Runtime performance?

I think another very interesting thing would be an analysis that shows 
how much of the hot loops we can optimize. You can use such an analysis 
also to estimate the possible speedups we can achieve. Andreas (CCed) 
may be able to help you with some performance measurements he has 
already taken.

> 12w Complete paperwork.

What is paperwork? And why does is take a week?

I also think it would be great if you could keep track of the code 
coverage improvement you achieve on the llvm testsuite.

I added a lot of remarks, mainly because I am really interested in such 
a project. Please feel free to ask back if you need any help.

Cheers
Tobi