Actually GCC has way more than 50 compiler options. In addition, this work actually goes deep into GCC, modifying the code and exposing many more optimisations that are not available with standard compile flags.
Further, you can reorder these optimisations, which really does give different results. All this combines to give a huge optimisation space which is suitable for tackling with machine learning.
Sure, it's not really AI, it's machine learning. AI is just a more media friendly term I guess.
You are right that many people have been doing iterative optimisation (what you describe) for years, especially for embedded systems, however this is a little different.
In that scenario, all the learned information about the program is thrown out at the end of the process every time. In this scenario, we try to build a compiler that remembers what kinds of optimisations and what order of optimisation was good for a particular kind of program. Then when we see a new program similar to that, we can use that offline knowledge.
I'm one of the members of this project. At the moment, the main way in which the system works is to do a quick static analysis step before compilation which gives a set of program features.
We iteratively try many different optimisations on the code (and do these optimisations in many different orders) in order to try to work out which combinations of optimisations work well on a particular program.
Then, using fairly standard machine learning techniques, we use the program features derived from a new program to see which of our existing modelled programs the new one is most similar to, and proceed from there.
We are replacing the man-made (and often totally arbitrary) heuristics within the compiler with a more statistically valid approach.
Slashdot Mirror
Further, you can reorder these optimisations, which really does give different results. All this combines to give a huge optimisation space which is suitable for tackling with machine learning.
You are right that many people have been doing iterative optimisation (what you describe) for years, especially for embedded systems, however this is a little different.
In that scenario, all the learned information about the program is thrown out at the end of the process every time. In this scenario, we try to build a compiler that remembers what kinds of optimisations and what order of optimisation was good for a particular kind of program. Then when we see a new program similar to that, we can use that offline knowledge.
I'm one of the members of this project. At the moment, the main way in which the system works is to do a quick static analysis step before compilation which gives a set of program features. We iteratively try many different optimisations on the code (and do these optimisations in many different orders) in order to try to work out which combinations of optimisations work well on a particular program. Then, using fairly standard machine learning techniques, we use the program features derived from a new program to see which of our existing modelled programs the new one is most similar to, and proceed from there. We are replacing the man-made (and often totally arbitrary) heuristics within the compiler with a more statistically valid approach.