[llvm-dev] -time-passes vs multiple pass managers

[Jay Foad via llvm-dev]

Hi,

I'm using a command line compiler driver
(https://github.com/GPUOpen-Drivers/llpc/blob/dev/llpc/docs/amdllpc.md)
that runs two separate pass pipelines with separate (legacy) pass
managers: first an IR optimization pipeline, and then a codegen
pipeline.

I have noticed that -time-passes sometimes prints the wrong name for
passes in the report:

===-------------------------------------------------------------------------===
                      ... Pass execution timing report ...
===-------------------------------------------------------------------------===
  Total Execution Time: 0.1561 seconds (21.9299 wall clock)

   ---User Time---   --System Time--   --User+System--   ---Wall
Time---  --- Name ---
   0.0009 (  0.7%)   0.0034 ( 17.9%)   0.0043 (  2.8%)  21.5917 (
98.5%)  Lower SPIR-V constant immediate store
   0.0005 (  0.3%)   0.0000 (  0.0%)   0.0005 (  0.3%)   0.1838 (
0.8%)  Global Variable Optimizer #2
   0.0244 ( 17.8%)   0.0014 (  7.5%)   0.0259 ( 16.6%)   0.0259 (
0.1%)  Machine Instruction Scheduler
   0.0185 ( 13.5%)   0.0000 (  0.0%)   0.0185 ( 11.9%)   0.0185 (
0.1%)  AMDGPU DAG->DAG Pattern Instruction Selection

The first entry here "Lower SPIR-V constant immediate store" should
really be "Greedy Register Allocator".

The problem seems to be that PassTimingInfo has a singleton instance
TheTimeInfo, which has a TimingData map, which is keyed off
PassInstanceID which is really just the address of a pass cast to
void*. This map is never cleared, so it'll remember info about a pass
which was created for the first pass manager and then destroyed. Then,
for the second pass manager, we can create a different pass instance
which happens to have the same address, and TheTimeInfo will use stale
data from the map.

Do other driver tools have a similar problem? What would a good
solution be? I did wonder about making the driver tool call
reportAndResetTimings after running the first pass pipeline, but that
still doesn't clear the TimingData map, so I don't think it would
help.

Thanks,
Jay.