From cTuning.org
Contents |
Ideas
Record IP passes per main input file
Motivation: Different main input file can have different IP passes. For example, if one file has only data structure defination but no function, then no IP passes will run, and nothing will be recorded. -- Susgested by Yuanjie Huang
Save XMLs in folder hierarchy
Motivation: Trying to save XMLs in one folder while avioding name conflicts results in strange file names and conplex naming rules. It might be a good idea to keep it in folder hierarchy (which clones the source code directory hierarchy in the adapt-xmls dir)like this:
adapt-xmls/
|-- main.c/
| `-- main.xml
`-- susan.c/
|-- susan_edges.xml
`-- susan_smoothing.xml
- Pros: We can find the xml file quickly and easily in programs that handles these XMLs.
- Cons: Some XMLs may lay in a deep directory hierarchy, making editing manually inconvenient.
- Unsolved Issue: When compiling source file from parent directory of current working dir, the XML files may "break the jail", i.e., be placed out of adapt-xmls directory
-- Suggested by Yuanjie Huang
Seperate generic_clone and instrumentation
Motivation: These two passes now seem quite twisted... and offering some duplicate functionality from fine-grain tuning. Maybe we could just leave these two passes simpler and thus more flexible by pass reordering? Then if we clone before instrumentation, then the instrumentation passes should target at the clones; while if we instrument before cloning, the instrument should be copied to each cloned function. -- Susgested by Yuanjie Huang
Todos
Make select function return value consistent with function name
Now when select function returns "1", "clone 0" will be called, it is confusing and error prone. We should this to a zero based consistent counting, i.e., return 0 for function clone 0,1 for function clone 1, etc. -- Susgested by Yang Chen & Yuanjie Huang
Allow options_clone to be omitted in XML
Current generic_cloning pass requires options_clone entry for each clone, which is not useful sometimes since we would like to do the tuning via XML for that cloned function.
PS: Liang has already write a patch for this issue, and Yuanjie will submit it to the svn when porting GSoC projects to GCC 4.5.
Set external library for instrument and generic_clone in XML files
The ICI_LIBS environment variable puts the limit that only one lib file can be used for all functions, and moreover it leads to confusion and bugs sometimes. So we should remove the environment variable and assign it in the XML file for each clone. --Suggested by Liang Peng
Implement clone and instrunmentation info with OO concept
Liang's implementation of clone and instrumentation pass store information in several link list, making it a bit hard to represent info in hierarchy... For instance, one clone pass may have several target functions, each with different number of clones, suffix to append, and libarary in which inserted function shall be searched... So I believe we should group these info into some structures with a bit OO concept. --Suggested by Yuanjie Huang