How to profile a GHC Plugin?

Thanks for the patience!

I am still not 100% what is happening, but it looks like the following:

• If you compile the plugin with -finfo-table-map but not ghc with ipe info, then ghc-stack-profiler-speedscope will fail to translate the .eventlog as the info prov entries of the plugin are not written to the eventlog. However, we can find the IPE info, so we include it in our profile, leading to the crash we observe in your example eventlog. Fun fun fun.
  • Probably even if GHC is compiled with IPE, then the info prov entries added by the plugin are probably still not written to the eventlog. Perhaps a GHC bug, or intended behaviour.
• It looked like lookupIPE got stuck for some keys, but I can’t reproduce this any more. Something to keep an eye out in the future.

To summarise, profiling the plugin with ghc-stack-profiler is quite tricky.

The way forward may be to compile GHC with the ipe transformer, but not to compile the plugin with -finfo-table-map.

To still get a reasonable profile for your plugin, you could use ghc-stack-annotations to insert some cost centre stack manually. Using this approach, I produced the following speedscope image:

Not great, but we can see something and with enough StackAnnotations, the profile might be helpful. Note, this only works with GHC 9.14.1+.

So, I am getting something , but it is hard to argue this is particularly useful as is.

It is also quite unfortunate, that it is quite difficult to use StackAnnotations reliably in non IO code.

Here is my example project:

github.com

GitHub - fendor/ghc-stack-profiler-with-ghc-plugin: Example project profiling a GHC plugin

Example project profiling a GHC plugin

Wild ideas to get IPE information for the plugin as well:

We need the IPE info from the plugin. We could try to index them somehow via ipedb and then instruct ghc-stack-profiler-speedscope to use ipedb to find IPE info instead of relying on the .eventlog.

But how do we get the IPE info from the plugin? I am not sure.