As a part of my GSoC project to integrate Julia and Polly-ACC, I’m looking at using run-time information to perform better optimisations.
The first thing would be to inform Polly about the “values” of function parameters. “Values” could include,
- Numerical parameters (Int,Float).
- Size and Type information of array parameters.
This information can help Polly figure out the most appropriate transformation. A possible scheme would be to leave this information in the IR when functions are annotated with
llvm.expect or llvm.assume intrinsics (llvm.expect might be removed in the future)
assignments to specially named variables like %param.0 (which is the value of the first parameter), %param.1.dim1 (number of elements in the 1st dimension of a 2nd function parameter) etc.
Polly’s GPU optimizer, ppcg, is then fed this data.
The second step would be to pick and run the most appropriate code according to the parameters. The implementation of this step depends on the way the multiple machine-code definitions (each appropriate for a particular set of parameters) of the same function are going to be stored.
In this regard, I’d like to know if it’s possible to make Julia maintain multiple function machine-code definitions of the same function for the same sequence of Types of the parameters, yet, differ in being
appropriate for a particular range of values of the parameters. E.g.
vector_add(a,b) could have,
- An x86 definition for when size(a) < 1,000,000 which runs entirely on the CPU
- And a definition with an additional NVPTX kernel for when size(a) > 1,000,000
The pick part of the step would have to reflect the way
ppcg would optimize for “case” to select the correct code.
Instead of that,we could update the machine code to include code to handle a new “case” and embed a fence to direct the program control to the code appropriate for a given set of values of the parameters.
Please share your thoughts.