Enable pass timings reporting with NewPassManager

[yashssh]

Enable LLVM Pass timings reporting with NewPassManager, to be used by Numba

[gmarkall]

Thanks for the PR! I have left some comments on the diff - mostly I think there's some inconsistencies in the naming of things.

The main thing I'm unclear about is whether it makes sense to disable pass timing when reporting the timings. The old pass manager seems to have report / reset as being distinct from disabling it. What is the reason for the change in API here?

Alternatively, should the set_time_passes() method for the new pass manager also handle both enabling and disabling, and reset_and_report_timings() only reset and report (not disable)?

[gmarkall]

Is there some asymmetry here - do pass instrumentation callbacks need to be unregistered if we've disabled pass timing?

[yashssh]

No. A unique PICallbacks object belongs to PassBuilder object and is used to do stuff like this(hooks to enable/disable pass timings) after the optimisation pipeline has been built.

[gmarkall]

I think this also disables pass timing.

[yashssh]

The main thing I'm unclear about is whether it makes sense to disable pass timing when reporting the timings. The old pass manager seems to have report / reset as being distinct from disabling it. What is the reason for the change in API here?

Pass timings monitoring was always reset and disabled after the report generation across all the examples I saw. Hence, I though reset_and_report_timings() might should implicitly disable it. But re-reading all the code the APIs do seem confusing because of the duplication and names.

What do you think about

1. Renaming the new APIs to enable_pass_timings and report_reset_and_disable_pass_timings. I don't want to re-use the old set_pass_timings as the reset_and_report_timings API for the NewPassManager "had" to be tied with PassBuilderObject. It might be good idea to mark the old one as deprecated though.
2. Alternatively we can keep the same mechanism as the Legacy PM with a switch API (set_time_passes) and a report API (reset_and_report_timings) both tied to PassBuilder.

[gmarkall]

What do you think about

I'd prefer option 1, but call the functions start_pass_timing and finish_pass_timing, where finish_pass_timing still returns the report. I think it was getting overly complicated putting everything the function does to achieve its goal in its name.

[yashssh]

Thanks for review :) I have updated all the API names as per your suggestions.