[all-commits] [llvm/llvm-project] f6ddf7: [LowerTypeTests] Support generating Armv6-M jump t...

[Simon Tatham via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: f6ddf7781471b71243fa3c3ae7c93073f95c7dff
      https://github.com/llvm/llvm-project/commit/f6ddf7781471b71243fa3c3ae7c93073f95c7dff
  Author: Simon Tatham <simon.tatham at arm.com>
  Date:   2023-02-16 (Thu, 16 Feb 2023)

  Changed paths:
    M llvm/include/llvm/Analysis/TargetTransformInfo.h
    M llvm/include/llvm/Analysis/TargetTransformInfoImpl.h
    M llvm/lib/Analysis/TargetTransformInfo.cpp
    M llvm/lib/Target/ARM/ARMTargetTransformInfo.cpp
    M llvm/lib/Target/ARM/ARMTargetTransformInfo.h
    M llvm/lib/Transforms/IPO/LowerTypeTests.cpp
    M llvm/test/Transforms/LowerTypeTests/function-arm-thumb.ll
    M llvm/test/Transforms/LowerTypeTests/function.ll

  Log Message:
  -----------
  [LowerTypeTests] Support generating Armv6-M jump tables.

The LowerTypeTests pass emits a jump table in the form of an
`inlineasm` IR node containing a string representation of some
assembly. It tests the target triple to see what architecture it
should be generating assembly for. But that's not good enough for
`Triple::thumb`, because the 32-bit PC-relative `b.w` branch
instruction isn't available in all supported architecture versions. In
particular, Armv6-M doesn't support that instruction (although the
similar Armv8-M Baseline does).

Most of this patch is concerned with working out whether the
compilation target is Armv6-M or not, which I'm doing by going through
all the functions in the module, retrieving a TargetTransformInfo for
each one, and querying it via a new method I've added to check its
SubtargetInfo. If any function's TTI indicates that it's targeting an
architecture supporting B.W, then we assume we're also allowed to use
B.W in the jump table.

The Armv6-M compatible jump table format requires a temporary
register, and therefore also has to use the stack in order to restore
that register.

Another consequence of this change is that jump tables on Arm/Thumb
are no longer always the same size. In particular, on an architecture
that supports Arm and Thumb-1 but not Thumb-2, the Arm and Thumb
tables are different sizes from //each other//. As a consequence,
``getJumpTableEntrySize`` can no longer base its answer on the target
triple's architecture: it has to take into account the decision that
``selectJumpTableArmEncoding`` made, which meant I had to move that
function to an earlier point in the code and store its answer in the
``LowerTypeTestsModule`` class.

Reviewed By: lenary

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