Extract MHP analysis, simplify printing in race output

[sim642]

Closes #571. Closes #552.

Changes

1. Extracts the MHP component of accesses to be provided by a separately activated mhp analysis, as suggested by Configuration of access collecting precision and performance #571 (comment). That analysis does nothing on its own, but just provides the more precise MHP component to accesses using data queried from other analyses.
2. The mhp analysis now needs to be explicitly enabled, it's not activated by default, because it's not clear whether its worth doing on most benchmarks where there are other bigger sources of imprecision. It's now easy to experiment either way and if useful for a benchmark, add a conf file. The few tests for MHP races now explicitly activate it.
3. History thread ID prefixes are now "unreversed", so previous [t1, main] is shown as [main, t1]. The reversed order is an internal optimization which could be misleading compared to the relational traces paper.
4. History thread ID sets are omitted when empty, so previous ([t1, main], {}) is shown as [main, t1].
5. If created or must_joined components of MHP are empty, they are omitted for clarity.

[michael-schwarz]

It makes sense to have it configurable... What strikes me as odd though is that in the default setting we now compute the expensive thread ids, only to then not really use them.

This seems strange, so I'd suggest we enable this by default.

[sim642]

That's true... I guess my point is even a bit broader and orthogonal then because history thread IDs aren't used by default analyses and privatizations either. So maybe all the bigger benchmarking should start with the cheaper old thread IDs.

I suppose I could just add mhp to default analyses then still.

[michael-schwarz]

I think the changes where we add the mhp analysis to regression tests can be reverted, as it is now part of the defaults, right?

[sim642]

I think the changes where we add the mhp analysis to regression tests can be reverted, as it is now part of the defaults, right?

Could be, but the test suite is more robust this way when the feature under test is made explicit. Otherwise changes in the defaults could cause tests to fail, just because there's an implicit assumption about what the defaults are, not that disabling mhp is an unsoundness problem or something.

[michael-schwarz]

Could be, but the test suite is more robust this way when the feature under test is made explicit. Otherwise changes in the defaults could cause tests to fail, just because there's an implicit assumption about what the defaults are, not that disabling mhp is an unsoundness problem or something.

That's to some extent a departure from what we've been doing for other tests, but I guess it makes sense here.