If the parameters of the target cache (i.e., cache level sizes, cache level associativities) are not specified or have wrong values, we use ones for parameters of the macro-kernel and do not perform data-layout optimizations of the matrix multiplication. In this patch we specify the default values of the cache parameters to be able to apply the pattern matching optimizations even in this case. Since there is no typical values of this parameters, we use the parameters of Intel Core i7-3820 SandyBridge that also help to attain the high-performance on IBM POWER System S822 and IBM Power 730 Express server.
Details
- Reviewers
Meinersbur grosser jdoerfert - Commits
- rG4d5a9172875c: Use typed enums to model MemoryKind and move MemoryKind out of ScopArrayInfo
rG1c2927b20929: Specify the default values of the cache parameters
rPLO292030: Use typed enums to model MemoryKind and move MemoryKind out of ScopArrayInfo
rPLO290518: Specify the default values of the cache parameters
rL292030: Use typed enums to model MemoryKind and move MemoryKind out of ScopArrayInfo
rL290518: Specify the default values of the cache parameters
Diff Detail
Event Timeline
Hi Roman,
thanks for the patch. I like the idea of this patch, but two comments:
- Please specify in the commit message and as comment in the code where/how you derived these values.
- I do not understand why you introduce new command line parameters. Could you not just add cl::init(num) to the existing parameters?
Hi Roman,
thanks for the patch. I like the idea of this patch, but two comments:
- Please specify in the commit message and as comment in the code where/how you derived these values.
Hi Tobias,
thanks for the comments! I've updated it.
- I do not understand why you introduce new command line parameters. Could you not just add cl::init(num) to the existing parameters?
As far as I understand, the cl::init attribute can specify an initial value only for a scalar option. Is there a workaround to use cl::init with the cl::list class?
Right. I did not see this. I see two options to work around this. Either we split the options into "-polly-target-1st-level-cache-associativity", "-polly-target-2nd-level-cache-associativity", or you add a static constant that contains the default cache sizes and use it in case the cache associativity list is of length zero.
But adding more options seems to be unnecessary (even though we have this with the cache size).