[PATCH] D76921: [llvm-exegesis] 'Min' repetition mode

Roman Lebedev via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 31 06:37:16 PDT 2020


lebedev.ri added inline comments.


================
Comment at: llvm/tools/llvm-exegesis/lib/BenchmarkRunner.cpp:108
+
+  for (const std::unique_ptr<const SnippetRepetitor> &Repetitor : Repetitors) {
+    // Assemble at least kMinInstructionsForSnippet instructions by repeating
----------------
gchatelet wrote:
> lebedev.ri wrote:
> > lebedev.ri wrote:
> > > gchatelet wrote:
> > > > The scope of the for loop is pretty big. I think it would be better to create a separate function:
> > > > ```
> > > > for (const std::unique_ptr<const SnippetRepetitor> &Repetitor : Repetitors) {
> > > >   if (auto InstrBenchmarkOrErr = runOneBenchmark(InstrBenchmark)) {
> > > >     // On success, aggregate this run
> > > >     ...
> > > >   } else {
> > > >     // On error, extract the Error value and return it.
> > > >     return InstrBenchmarkOrErr.takeError();
> > > >   }
> > > > }
> > > > ```
> > > > 
> > > > This way you also don't have to have the RAII cleaner.
> > > Hmm. I agree that the loop is getting big, but are you very sure about the fix?
> > > 
> > > Like i said in the patch's description, i tried a variation of that approach
> > > initially, and i'd say the result is much uglier. Instead of having one place
> > > that fills a single `InstrBenchmark` and just ensuring it doesn't completely
> > > override previous results, we will now need to keep two places in sync.
> > > 
> > > Please do note that we have two types of errors here,
> > > a fatal one that we signal via `Error`, and a measurement-time error,
> > > that we squash and stash into `InstrBenchmark.Error`. The latter
> > > must not be reported as a fatal error, but it must interrupt aggregation.
> > > So we won't avoid the RAII, just change it's form.
> > > 
> > > override previous results, we will now need to keep two places in sync.
> > 
> > Err, to be more specific:
> > We will then need to just rename the existing `BenchmarkRunner::runConfiguration()`
> > as that `runOneBenchmark()`, and new `BenchmarkRunner::runConfiguration()`
> > would need to know how to aggregate every field of fresh `InstructionBenchmark`
> > returned from `BenchmarkRunner::runOneBenchmark()` into the 'aggregate' report.
> > This seems more complex than teaching `BenchmarkRunner::runConfiguration()`
> > itself to do just that within the per-Repetitor loop.
> Acknowledge.
> I'm not a huge fan of the RAII cleaner which spans the whole function and needs comments to be understood.
> Maybe a custom struct would convey more semantics, it's not a lot more code.
> ```
> struct ClearBenchmarkOnReturn {
>   ClearBenchmarkOnReturn(InstructionBenchmark* IB) : IB(IB)
>   ~ClearBenchmarkOnReturn() { if(Clear) IB->Measurements.clear(); }
> 
>   void disarm() { Clear = false; }
> private:
>   InstructionBenchmark* const IB;
>   bool Clear = true;
> };
> ----------------------
> 
> ClearBenchmarkOnReturn CBOR(&InstrBenchmark);
> 
> ...
> 
> CBOR.disarm();
> 
> 
> ```
Ok, sure, that i can do.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76921/new/

https://reviews.llvm.org/D76921





More information about the llvm-commits mailing list