[llvm-dev] [Q] What can drive compiler performance improvements in the future?

Mircea Trofin via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 22 16:57:22 PST 2021


On Mon, Feb 22, 2021 at 4:50 PM Denis Bakhvalov via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hello,
>
> I'll be giving a short presentation on the LLVM performance workshop soon
> and I want to touch on the topic of future performance improvements. I
> decided to ask the community about what can drive performance improvements
> in a classic C++ LLVM compiler CPU backend in the future? If I summarize
> all the thoughts and opinions, I think it would be an interesting
> discussion.
>
> There is already a body of research on the topic, including [1] which
> talks about superoptimizers, but maybe anybody has some interesting new
> ideas.
> In particular, I'm interested to hear thoughts on the following things:
> 1. How big is the performance headroom in existing LLVM optimization
> passes?
> 2. I think PGO can play a bigger role in the future. I see the benefits of
> more optimizations being guided by profiling data. For example, there is
> potential for intelligent injection of memory prefetching hints based on HW
> telemetry data on modern Intel CPUs. This HW telemetry data allows finding
> memory accesses that miss in caches and estimate the prefetch window (in
> cycles). Using this data compiler can determine the place for a prefetch
> hint. Obviously, there are lots of limitations, but it's just a thought.
> BTW, the same can be done for PGO-driven branch-to-cmov conversion
> (fighting branch mispredictions).
> 3. ML opportunities in compiler tooling. For example, code similarity
> analysis [2][3] opens a wide range of opportunities, e.g. build a
> recommendation system that will suggest a better performing code sequence.
>
on this, also: replacing hand-crafted heuristics with machine learned
policies, for those passes that are heuristics driven - like inlining,
regalloc, instruction selection, etc. Same for cost models.


> Please also share any thoughts you have that are not on this list.
>
> If that topic was discussed in the past, sorry, and please send links to
> those discussions.
>
> -Denis
> https://easyperf.net
>
> [1]: https://arxiv.org/abs/1809.02161
> [2]: https://doi.org/10.1145/3360578
> [3]: https://arxiv.org/abs/2006.05265
>
>
>
>
> _______________________________________________
> 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/20210222/f9e567dd/attachment.html>


More information about the llvm-dev mailing list