[llvm-dev] ?==?utf-8?q? [llvm-exegesis]?==?utf-8?q? [RFC] Renaming Uops- classes

[Milos Stojanovic via llvm-dev]

The patch has been submitted: https://reviews.llvm.org/D72928.

Regards,
Miloš

-------- Original Message --------
Subject: Re: [llvm-exegesis] [RFC] Renaming Uops- classes
Date: Friday, January 17, 2020 10:05 CET
From: Guillaume Chatelet <gchatelet at google.com>
To: Clement Courbet <courbet at google.com>
CC: Milos Stojanovic <Milos.Stojanovic at rt-rk.com>, llvm-dev <llvm-dev at lists.llvm.org>
References: <1943-5e20b380-5-48e3c400 at 242609111> 




 Yes I concur. Thx for the suggestion Miloš! On Fri, Jan 17, 2020 at 10:03 AM Clement Courbet <courbet at google.com> wrote:Hi Milos, I think this is a good idea. This only applies to to {Latency,Uops}SnippetGenerator though (renamed to {Serial,Parallel}SnippetGenerator) - I think the benchmark runners themselves should remained the same, as they are really measuring latency or uops.  On Thu, Jan 16, 2020 at 8:04 PM Milos Stojanovic <Milos.Stojanovic at rt-rk.com> wrote:Since the option of running -mode=inverse_throughput was added to llvm-exegesis the names of classes like UopsSnippetGenerator and UopsBenchmarkRunner, that this mode shares with uops, started to be less descriptive.

Inverse_throughput doesn't use the uops counters, so for example, the instruction layout shared between these two modes is really connected to parallelism, not uops. It's doubly confusing for architectures that don't even have any uops counters to constantly use classes with Uops in their name.
Because of this it would probably be easier to follow the code if the shared classes/methods would be renamed to something like Parallel- instead of Uops-. To keep it consistent Latency- could also be renamed to Serial-.

I can submit a patch if you think making this change would be reasonable.

Regards,
Miloš+ej8nvwnpwvv_dgwqq at mail.gmail.com>
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200117/2cd03fd9/attachment.html>