[all-commits] [llvm/llvm-project] e81796: [RISCV] Collapse fast unaligned access into a sing...

[Philip Reames via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: e81796671890b59c110f8e41adc7ca26f8484d20
      https://github.com/llvm/llvm-project/commit/e81796671890b59c110f8e41adc7ca26f8484d20
  Author: Philip Reames <preames at rivosinc.com>
  Date:   2023-12-01 (Fri, 01 Dec 2023)

  Changed paths:
    M clang/lib/Basic/Targets/RISCV.cpp
    M clang/lib/Driver/ToolChains/Arch/RISCV.cpp
    M clang/test/Driver/riscv-features.c
    M llvm/lib/Target/RISCV/RISCVExpandPseudoInsts.cpp
    M llvm/lib/Target/RISCV/RISCVFeatures.td
    M llvm/lib/Target/RISCV/RISCVISelLowering.cpp
    M llvm/lib/Target/RISCV/RISCVTargetTransformInfo.h
    M llvm/test/CodeGen/RISCV/memcpy-inline.ll
    M llvm/test/CodeGen/RISCV/memcpy.ll
    M llvm/test/CodeGen/RISCV/memset-inline.ll
    M llvm/test/CodeGen/RISCV/pr56110.ll
    M llvm/test/CodeGen/RISCV/riscv-func-target-feature.ll
    M llvm/test/CodeGen/RISCV/rvv/concat-vectors-constant-stride.ll
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-strided-load-combine.ll
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-unaligned.ll
    M llvm/test/CodeGen/RISCV/rvv/memcpy-inline.ll
    M llvm/test/CodeGen/RISCV/rvv/memset-inline.ll
    M llvm/test/CodeGen/RISCV/rvv/unaligned-loads-stores.ll
    M llvm/test/CodeGen/RISCV/unaligned-load-store.ll
    M llvm/utils/TableGen/RISCVTargetDefEmitter.cpp

  Log Message:
  -----------
  [RISCV] Collapse fast unaligned access into a single feature [nfc-ish] (#73971)

When we'd originally added unaligned-scalar-mem and
unaligned-vector-mem, they were separated into two parts under the
theory that some processor might implement one, but not the other. At
the moment, we don't have evidence of such a processor. The C/C++ level
interface, and the clang driver command lines have settled on a single
unaligned flag which indicates both scalar and vector support unaligned.
Given that, let's remove the test matrix complexity for a set of
configurations which don't appear useful.

Given these are internal feature names, I don't think we need to provide
any forward compatibility. Anyone disagree?

Note: The immediate trigger for this patch was finding another case
where the unaligned-vector-mem wasn't being properly serialized to IR
from clang which resulted in problems reproducing assembly from clang's
-emit-llvm feature. Instead of fixing this, I decided getting rid of the
complexity was the better approach.