[llvm-dev] RFC: a practical mechanism for applying Machine Learning for optimization policies in LLVM

[Xinliang David Li via llvm-dev]

On Thu, Apr 9, 2020 at 11:02 AM Mircea Trofin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
> On Thu, Apr 9, 2020 at 10:47 AM Adrian Prantl <aprantl at apple.com> wrote:
>
>>
>>
>> > On Apr 8, 2020, at 2:04 PM, Mircea Trofin via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>> >
>> > TL;DR; We can improve compiler optimizations driven by heuristics by
>> replacing those heuristics with machine-learned policies (ML models).
>> Policies are trained offline and ship as part of the compiler. Determinism
>> is maintained because models are fixed when the compiler is operating in
>> production. Fine-tuning or regressions may be handled by incorporating the
>> interesting cases in the ML training set, retraining the compiler, and
>> redeploying it.
>> > For a first milestone, we chose inlining for size (-Oz) on X86-64. We
>> were able to train an ML model to produce binaries 1.5-6% smaller than -Oz
>> of tip-of-tree. The trained model appears to generalize well over a diverse
>> set of binaries. Compile time is increased marginally (under 5%). The model
>> also happens to produce slightly better - performing code under SPEC2006 -
>> total score improvement by 1.75%. As we only wanted to verify there is no
>> significant regression in SPEC, and given the milestone goals, we haven’t
>> dug any deeper into the speed results.
>> >
>>
>> How generally applicable are the results? I find it easy to believe that
>> if, for example, you train a model on SPEC2006, you will get fantastic
>> results when compiling SPEC2006, but does that translate well to other
>> inputs?
>
>
> The current model was trained on an internal corpus of ~25K modules,
> obtained from an internal "search" binary. Only ~20 or so are shared with
> llvm, for example. In particular, no SPEC modules were used for training.
> So the results appear to generalize reasonably well.
>
> Or is the idea to train the compiler on the exact input program to be
>> compiled, (perhaps in a CI of sorts), so you end up with a specialized
>> compiler for each input program?
>>
>
> That's the anti-goal :)
>

It is still an option if a user chooses to do so :)


> The hope is to have reference policies, trained from a representative
> corpus, which are 'good enough' for general use (just like manual
> heuristics today), while having a systematic methodology for interested
> parties to go the extra step and fine-tune (retrain) to their specifics.
>
>
>>
>> -- adrian
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200409/f19b868d/attachment.html>