Halide
Halide copied to clipboard
halide
Innopeaktech/hexagon instrumentation
This is a set of utilities for deterministic profiling of Halide code generated for the Hexagon DSP. It works by injecting code during Halide Generator invocation which calls a Qualcomm DSP library which emits the profiling data on logcat. The logcat output is then converted to JSON-formatted profiles with another logcat2json, and these JSON files can then be visualized with some python scripts that create text reports and a Graphviz dotfile.
@vladl-innopeaktech - thank you for this PR. @aankit-ca, @suyogsarda - FYI. Can you PTAL?
@aankit-ca I've added comments to the code, is this what you had in mind?
Hey @vladl-innopeaktech, I'll take a look at the patch today. Can you add a use-case to show how it can be used.
Actually, I'm wondering if the overall structure of this makes the most sense for upstreaming... it looks to me like the custom lowering pass should be controlled by a feature flag, rather than by interposing a Generator subclass between the existing first-party generator infra and the user's actual generator.
As for the profiling.cpp stuff... maybe some of it can be a runtime module that's only included when the feature flag is present. I think there's some precedent for this.
The command-line tools for interpreting the output seem fine as they are.
This way enabling/disabling this instrumentation can happen at the command line or in the build system, rather than by necessarily changing sources. I think this feature will be better for everyone if this is the case. New users won't have to change their code, for one.
That sounds good. The flag would need to be applied at the build configuration level, right? Where could I look for an example of this runtime module design?
@alexreinking I have put the build behind a feature flag (I think) and am building the DSP library based on whether or not the Hexagon SDK environment is present. I should put a prebuilt copy somewhere in the distribution as well, do you have any suggestions on where?
I'm not sure how to set the InstrumentedGenerator using a feature flag. This is something that would be controlled by a generator runtime argument? I can imagine pulling this off by setting a define like #define Generator InstrumentedGenerator before compilation based on the presence of an argument. Not sure that is gonna be the right way.
I haven't really used cmake's install functionality before so I could be missing a lot of important practices here. What is the right way to set up symlinks (without the .py extension) at installation time?
@alexreinking I've made an attempt at enabling the instrumentation without the user having to include. I wound up moving the header into src as I needed visibility there, although if we need better separation, I could declare an external function pointer instead. Is this similar to what you had in mind?
@vladl-innopeaktech - I can take a look, but I don't feel comfortable being the sole approver for a change as large as this.
@alexreinking It's definitely not ready to merge yet, I just need a few pointers on how to proceed. Once I've got everything in place and then test it, we could bring more reviewers in.