[llvm] [BOLT][heatmap] Produce zoomed-out heatmaps (PR #140153)

Amir Ayupov via llvm-commits llvm-commits at lists.llvm.org
Fri May 30 11:39:34 PDT 2025


aaupov wrote:

> > @maksfb:
> > > * If we are producing multiple files by default, we might have to change docs in more places.
> > 
> > 
> > Makes sense. I'll update heatmap doc, anything else?
> 
> `llvm-bolt-heatmap` usage message if possible.

Added usage message:
```
OVERVIEW:  BOLT Code Heatmap tool

  Produces code heatmaps using sampled profile

  Inputs:
  - Binary (supports BOLT-optimized binaries),
  - Sampled profile collected from the binary:
    - perf data or pre-aggregated profile data (instrumentation profile not supported)
    - perf data can have basic (IP) or branch-stack (LBR) samples

  Outputs:
  - Heatmaps: colored ASCII (requires a color-capable terminal or a conversion tool like `aha`)
    Multiple heatmaps are produced by default with different granularities (set by `block-size` option)
  - Section hotness: per-section samples% and utilization%
  - Cumulative distribution: working set size corresponding to a given percentile of samples
```

> 
> > > * I find the power-of-two limitation for the scale unnecessary.
> > 
> > 
> > This made it impossible to enter invalid scales. While working on a custom parser, I realized that a better UX would be to allow specifying bucket sizes in natural units (e.g. 4KB, 1MB):
> > ```
> > --block-size=default_size[,size1,...]
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > If you agree, I'll switch to that and print warnings in case of invalid sizes/rescales.
> 
> Okay. Then the burden falls on the proper UI messaging and error/warning diagnostics.

Added check for sorted values. Not checking the provided values though.

> 
> > > * The variance in default scale steps looks a bit unnatural (64, 4, 64 again). I would keep just 64 and 64 making the default sizes 64 bytes, 4 KB, 256 KB.
> > 
> > 
> > It's the downstream of bucket size selection. 1MB works really well for XL binaries, to have a high-level view of the whole address space. I'd like to keep 1MB for that reason. We can add 256KB for sure.
> > LMK if that sounds good.
> 
> If 256KB is difficult to read for large binaries, 1MB works for me.

256KB works well for large binaries.

https://github.com/llvm/llvm-project/pull/140153


More information about the llvm-commits mailing list