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

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š
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200116/badd6db7/attachment.html>

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š
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200117/7ae0e407/attachment.html>

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š
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200117/eb19d2d2/attachment.html>