[all-commits] [llvm/llvm-project] 22e199: [RISCV] Accept zicsr and zifencei command line opt...

[Philip Reames via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 22e199e6afb1263c943c0c0d4498694e15bf8a16
      https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694e15bf8a16
  Author: Philip Reames <preames at rivosinc.com>
  Date:   2023-02-16 (Thu, 16 Feb 2023)

  Changed paths:
    M clang/test/Preprocessor/riscv-target-features.c
    M llvm/docs/RISCVUsage.rst
    M llvm/lib/Support/RISCVISAInfo.cpp
    M llvm/lib/Target/RISCV/RISCVFeatures.td
    M llvm/test/CodeGen/RISCV/attributes.ll
    M llvm/test/MC/RISCV/attribute-arch.s

  Log Message:
  -----------
  [RISCV] Accept zicsr and zifencei command line options

This change adds the definition of the two extensions, but does not either a) make any instruction conditional on them or b) enabled the extensions by default. (The *instructions* do remain enabled by default per ISA version 2.0 which is our current default.)

This is meant to be a building block towards something like https://reviews.llvm.org/D141666, and in the meantime, address one of the most surprising of the current user experience warts. The current behavior of rejecting the extensions at the command line despite emitting code which appears to use them is surprising to anyone not deeply versed in the details of this situation.

Between versions 2.0 and 2.1 of the base I specification, a backwards incompatible change was made to remove selected instructions and CSRs from the base ISA. These instructions were grouped into a set of new extensions (these), but were no longer required by the base ISA. This change is described in “Preface to Document Version 20190608-Base-Ratified” from the specification document.

As LLVM currently implements only version 2.0 of the base specification, accepting these extensions at the command line introduces a configuration which doesn't actually match any spec version. It's a pretty harmless variant since the 2.0 extension definitions, to my knowledge, exactly match the text from the 2.0 I text before they were moved into standalone extensions in 2.1 of I. (The version numbering in that sentence is a tad confusing to say the least. Hopefully I got it right.)

It is worth noting that we already have numerous examples of accepting extensions in the march string which didn't exist in version of the spec document corresponding to our current base I version, so this doesn't set any new precedent.

Differential Revision: https://reviews.llvm.org/D143953