[PATCH] D86177: [llvm-mca][NFC] Separate calculation of display data from its display in the summary and instruction info views

Thu Aug 20 01:25:46 PDT 2020

andreadb added a comment.

In D86177#2227126 <https://reviews.llvm.org/D86177#2227126>, @wolfgangp wrote:

> In D86177#2225748 <https://reviews.llvm.org/D86177#2225748>, @andreadb wrote:
>
>> Nice!
>
> Thank you Andrea!
>
>> I agree with Roman in that we should not guarantee stability of data and/or structure.
>> Also, changes to the output structure should always be advertised (for example, by adding a line in the release notes), so that people are always aware of it.
>
> I must confess I am not very informed about the issues regarding stability. Doesn't data stability depend on the scheduling model? I don't see how llvm-mca could guarantee it if that changes.

What I was trying to say is that the structure of the json report may change over time.

Future versions of mca may decide to structure data differently. Since we don't guarantee a stable structure for the json file, this may introduce incompatibilites in downstream tools which instead expect/assume a fixed/unchanging layout.

One way to solve this issue is by adding a version string to the json file, with the idea that each version string corresponds to a different structure of the json report.
It doesn't solve the incompatibility issue, but it allow tools to quickly identify incompatible files.

My other point was about the "stability of the data" (specifically: data generated by the default llvm-mca views).
Default mca views are not likely to change in future. So we can assume that the data generated by those views will always be the same. What could change is how data is layout in the final json report; Since the layout is not fixed, data may be moved to different objects/used by different name-value pairs etc.

If data doesn't change, and the only thing that changes is how data is mapped to the json structure, then it is possible to write an automated tool (e.g. an auto-upgrade script) which maps the data from an older report to the new json report structure. This again would probably require the presence of a string version.

In conclusion: if we really want to, in future we can always introduce a version string and write a simple auto-upgrade with simple rewriting rules for a few basic views.
However, yy personal opinion is that we should not worry about this (at least, not now).

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

https://reviews.llvm.org/D86177