[PATCH] D26855: New unsafe-fp-math implementation for X86 target

[Hal Finkel via Phabricator via llvm-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D26855#658647, @avt77 wrote:

> I got the first profiling data. In fact it's the same that was described by Sanjay:
>
> Samples: 1M of event 'cycles:pp', Event count (approx.): 1180464                                                                                                                                             
>  Overhead  Command  Source Shared Object  Source Symbol
>
>   15,65%  llc      llc                   [.] llvm::MachineTraceMetrics::Ensemble::computeInstrDepths
>   15,18%  llc      llc                   [.] getDataDeps
>    9,23%  llc      llc                   [.] llvm::MachineTraceMetrics::Ensemble::computeInstrHeights
>    8,29%  llc      llc                   [.] pushDepHeight
>    8,15%  llc      llc                   [.] llvm::MachineTraceMetrics::Ensemble::invhalidate
>    5,64%  llc      llc                   [.] llvm::TargetInstrInfo::defaultDefLatency
>    4,89%  llc      llc                   [.] llvm::MachineTraceMetrics::getResources
>    2,44%  llc      llc                   [.] llvm::X86InstrInfo::isHighLatencyDef
>   
>
> Should I try to cash the metrics or it's a question of a special patch?


I think you should look at caching them, or limiting their depth (beyond a certain point, the exact answer might not matter), or both.


https://reviews.llvm.org/D26855