summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/MachineTraceMetrics.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Add trace accessor methods, implement primitive if-conversion heuristic.Jakob Stoklund Olesen2012-08-071-0/+24
| | | | | | | | Compare the critical paths of the two traces through an if-conversion candidate. If the difference is larger than the branch brediction penalty, reject the if-conversion. If would never pay. llvm-svn: 161433
* Compute the critical path length through a trace.Jakob Stoklund Olesen2012-08-021-5/+69
| | | | | | | | | | | Whenever both instruction depths and instruction heights are known in a block, it is possible to compute the length of the critical path as max(depth+height) over the instructions in the block. The stored live-in lists make it possible to accurately compute the length of a critical path that bypasses the current (small) block. llvm-svn: 161197
* Compute instruction heights through a trace.Jakob Stoklund Olesen2012-08-011-10/+246
| | | | | | | | | | | | | | | | | | | The height on an instruction is the minimum number of cycles from the instruction is issued to the end of the trace. Heights are computed for all instructions in and below the trace center block. The method for computing heights is different from the depth computation. As we visit instructions in the trace bottom-up, heights of used instructions are pushed upwards. This way, we avoid scanning long use lists, looking for uses in the current trace. At each basic block boundary, a list of live-in registers and their minimum heights is saved in the trace block info. These live-in lists are used when restarting depth computations on a trace that converges with an already computed trace. They will also be used to accurately compute the critical path length. llvm-svn: 161138
* Add DataDep constructors. Explicitly check SSA form.Jakob Stoklund Olesen2012-08-011-20/+18
| | | | llvm-svn: 161115
* Compute instruction depths through the current trace.Jakob Stoklund Olesen2012-07-311-0/+232
| | | | | | | | | | | Assuming infinite issue width, compute the earliest each instruction in the trace can issue, when considering the latency of data dependencies. The issue cycle is record as a 'depth' from the beginning of the trace. This is half the computation required to find the length of the critical path through the trace. Heights are next. llvm-svn: 161074
* Rename CT -> MTM. MachineTraceMetrics is abbreviated MTM.Jakob Stoklund Olesen2012-07-311-12/+12
| | | | llvm-svn: 161072
* Avoid looking at stale data in verifyAnalysis().Jakob Stoklund Olesen2012-07-301-1/+4
| | | | llvm-svn: 161004
* Allow traces to enter nested loops.Jakob Stoklund Olesen2012-07-301-14/+29
| | | | | | | | | | | This lets traces include the final iteration of a nested loop above the center block, and the first iteration of a nested loop below the center block. We still don't allow traces to contain backedges, and traces are truncated where they would leave a loop, as seen from the center block. llvm-svn: 161003
* Assert that all trace candidate blocks have been visited by the PO.Jakob Stoklund Olesen2012-07-301-11/+6
| | | | | | | | | | When computing a trace, all the candidates for pred/succ must have been visited. Filter out back-edges first, though. The PO traversal ignores them. Thanks to Andy for spotting this in review. llvm-svn: 160995
* Hook into PassManager's analysis verification.Jakob Stoklund Olesen2012-07-301-1/+1
| | | | | | | By overriding Pass::verifyAnalysis(), the pass contents will be verified by the pass manager. llvm-svn: 160994
* Add MachineInstr::isTransient().Jakob Stoklund Olesen2012-07-301-23/+1
| | | | | | | | | | | This is a cleaned up version of the isFree() function in MachineTraceMetrics.cpp. Transient instructions are very unlikely to produce any code in the final output. Either because they get eliminated by RegisterCoalescing, or because they are pseudo-instructions like labels and debug values. llvm-svn: 160977
* Add MachineTraceMetrics::verify().Jakob Stoklund Olesen2012-07-301-10/+46
| | | | | | | This function verifies the consistency of cached data in the MachineTraceMetrics analysis. llvm-svn: 160976
* Verify that the CFG hasn't changed during invalidate().Jakob Stoklund Olesen2012-07-301-2/+12
| | | | | | | The MachineTraceMetrics analysis must be invalidated before modifying the CFG. This will catch some of the violations of that rule. llvm-svn: 160969
* Add more debug output to MachineTraceMetrics.Jakob Stoklund Olesen2012-07-271-1/+32
| | | | llvm-svn: 160905
* Keep track of the head and tail of the trace through each block.Jakob Stoklund Olesen2012-07-271-4/+12
| | | | | | | This makes it possible to quickly detect blocks that are outside the trace. llvm-svn: 160904
* Use an otherwise unused variable.Jakob Stoklund Olesen2012-07-261-1/+1
| | | | llvm-svn: 160798
* Start scaffolding for a MachineTraceMetrics analysis pass.Jakob Stoklund Olesen2012-07-261-0/+477
This is still a work in progress. Out-of-order CPUs usually execute instructions from multiple basic blocks simultaneously, so it is necessary to look at longer traces when estimating the performance effects of code transformations. The MachineTraceMetrics analysis will pick a typical trace through a given basic block and provide performance metrics for the trace. Metrics will include: - Instruction count through the trace. - Issue count per functional unit. - Critical path length, and per-instruction 'slack'. These metrics can be used to determine the performance limiting factor when executing the trace, and how it will be affected by a code transformation. Initially, this will be used by the early if-conversion pass. llvm-svn: 160796
OpenPOWER on IntegriCloud