Provenance request for the legacy GV100 Hotspot512 trace: capture manifest and producer build

[cudabinary]

Hello Accel-Sim maintainers,

Could you point us to any retained capture/build records for this specific legacy GV100 Hotspot trace?

Archive:
https://engineering.purdue.edu/tgrogers/accel-sim/traces/tesla-v100/latest/rodina-3.1.tgz

Member:
rodinia-3.1/9.1/hotspot-rodinia-3.1/512_2_2___data_temp_512___data_power_512_output_out/traces/kernel-1.traceg

Member size: 259,435,310 bytes
Member SHA-256, computed locally on the unchanged downloaded member:
4b6488c7b726928e1ecdd164e99c6140ca2fa0887859adc709d807ed7a3bc4f9

The header identifies _Z14calculate_tempiPfS_S_iiiiffffff, grid (43,43,1), block (16,16,1), binary version 70 (the trace-header field, not an ELF build ID). The accompanying run.sh uses a local nvbit/tools/traceall/traceall.so and post-traces-processing. It does not record their hashes or commits. We have not computed a whole-archive SHA-256; the member hash above is our local identifier, not a published checksum.

We saw the clarification in issue #398 that the public Rodinia traces are the original traces. Our remaining question is the producer build and recording contract for this exact member. The v2.0.1 manifest we inspected contains H200 workloads and does not identify it.

The reason for the request is address interpretation. In historical producer source blob baddd069511a604506815430037346319506f8c2, the emitted instruction mask is active_mask & predicate_mask, while address emission/compression uses active_mask. This is consistent with observed records such as a 28-lane effective mask with 32 address tokens. For 55,036 base/stride memory rows, we obtained unique execution-origin lanes under an assumed complete per-warp recording contract. That result remains conditional on verifying the actual producer contract and completeness of the recorded events. We are keeping the originals intact and marking capture provenance INCOMPLETE.

The most useful evidence would be:

1. A capture manifest, archived log, or release record linking this member (ideally its hash) to the producer and postprocessor used to create it.
2. The actual traceall.so binary used for this capture, or its SHA-256 and ELF build ID if one exists, together with the source revision and any local modifications needed to associate that binary with its build. A hash of a newly rebuilt binary would not identify the historical producer.
3. The corresponding NVBit version, CUDA/compiler versions, build flags, capture options, and postprocessor revision. For this member, did the producer emit active_mask & predicate_mask as the instruction mask while emitting/compressing addresses over active_mask? Were predicate-off events retained and per-warp event order preserved, without filtering, sampling, truncation, or post-capture address rewriting for this member?

A link to existing records is sufficient; we are not requesting a new capture or the whole dataset. If the binary or build records no longer exist, a qualified maintainer statement identifying what can and cannot be confirmed for this exact member would still help us keep the provenance boundary accurate.

Relevant references:
#398 (comment)

accel-sim-framework/util/tracer_nvbit/tracer_tool/tracer_tool.cu

Line 662 in 20cf50e

fprintf(resultsFile, "%08x ", ma->active_mask & ma->predicate_mask);

Thank you.