[PATCH] D66801: [X86][BtVer2] Fix latency and throughput of conditional SIMD store instructions.

[Andrea Di Biagio via Phabricator via llvm-commits]

andreadb added a comment.

In D66801#1653861 <https://reviews.llvm.org/D66801#1653861>, @RKSimon wrote:

> LGTM - thanks @andreadb I think this is the way to go. As ever its up to the people responsible for the other models to tweak as necessary, as you said this is NFC for everything but btver2.
>
> I don't see accurate numbers for these ops on Agner/instlatx64 for any target, I'm curious how they've checked the perf range for different mask register values (although Agner does mention that btver2 is often bad with VMASKMOVPS loads when mask == 0).
>
> @lebedev.ri By the looks of it llvm-exegesis always uses zero registers for those tests - does it alter if you hack in other values?


I was about to post a similar comment.

It may be worthy to rerun those experiments by forcing a different mask value. Otherwise, we don't know for sure if the zero-mask is treated specially on bdver2.

More in general: it would be better if exegesis uses a `all-ones` default for initial register values. That is what I tend to do when doing throughput analysis (actually, I tend to test both cases, i.e. the all-zero case and the all-ones case). On Jaguar, I know that no optimization is performed if registers are not set via a zero idiom. On entry to the benchmark loop, I set those registers to all-ones. For XMM/YMM registers, as you know, it is really straightforward (just use an all-ones (v)pcmpeq instead of a zero-idiom (v)xorps).
When reading counters, make sure that the initialization code is not counted too (to minimize the noise - all-ones idioms are executed, while all-zeroes are eliminated). I don't know exegesis enough, but I would advice for that change in default values if possible. At least, give an option for testing all-ones...


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

https://reviews.llvm.org/D66801