[PATCH] D85366: [RISCV] Disparage CSR instructions

[Evandro Menezes via Phabricator via llvm-commits]

evandro added a comment.

In D85366#2211716 <https://reviews.llvm.org/D85366#2211716>, @jrtc27 wrote:

> In D85366#2211651 <https://reviews.llvm.org/D85366#2211651>, @evandro wrote:
>
>> `hasSideEffects` may imply `isNotDuplicable`, especially when rematerializing, but the latter prevents duplication more extensively in the middle end (e.g., tail end duplication).
>
> But why does that matter? If LLVM decides it's better to fork a code path then let it, whether it's a CSR instruction or not really does not matter, it's just I-cache usage. In fact that's another reason why I _wouldn't_ want this change to go through.

Control registers may have their own requirements that are often akin to volatile memory.  In my view this is equivalent to `hasSideEffects` and `isNotDuplicable`.

>> Architecting reading the cycle counter to be like a GPR is not a given, since it's usually a side band register away from the register file.  Therefore, such instructions follow unusual paths in the architecture, when methinks that `hasNoSchedulingInfo` makes sense.
>
> Did you read what I said? I didn't say it was a given. I said it was a possibility, and something that _should_ be done in a real high-end core, but no such implementation yet exists. The performance monitoring counters are _meant_ to be cheap to access per the spec ("Additional counters should be provided to help diagnose performance problems and these should be made accessible from user-level application code with low overhead.") and that's key to not perturbing the behaviour of the system by probing it. Yes, _some_ implementations (currently all that I know of) make them expensive to read. But that does not mean we should declare that _all_ implementations forever will, and having scheduling info is _key_ to being able to capture that. If your architecture makes them really expensive then go and tell LLVM that by writing a processor-specific schedule description. But don't try and enforce a one-size-fits-all approach for something where that's not true.

High end cores are the least likely to implement this possibility.  This is the state of things among all such cases currently.

But you are misinterpreting what `hasNoSchedulingInfo` does:

> This instruction is not expected to be queried for scheduling latencies and therefore needs no scheduling information even for a complete scheduling model.

IOW, it just makes `TableGen` happy if the its scheduling information is not provided.  If it is, it will continue to be happy, and so will the scheduler.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D85366