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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Jeremy Morse via llvm-dev
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š
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [llvm-exegesis] [RFC] Renaming Uops- classes

Jeremy Morse via llvm-dev
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 <[hidden email]> 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š

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [llvm-exegesis] [RFC] Renaming Uops- classes

Jeremy Morse via llvm-dev
Yes I concur. Thx for the suggestion Miloš!

On Fri, Jan 17, 2020 at 10:03 AM Clement Courbet <[hidden email]> 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 <[hidden email]> 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š

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Jeremy Morse 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 <[hidden email]>
To: Clement Courbet <[hidden email]>
CC: Milos Stojanovic <[hidden email]>, llvm-dev <[hidden email]>
References: <1943-5e20b380-5-48e3c400@242609111>




 
Yes I concur. Thx for the suggestion Miloš!
 
On Fri, Jan 17, 2020 at 10:03 AM Clement Courbet <[hidden email]> 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 <[hidden email]> 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š

 
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev