[all-commits] [llvm/llvm-project] 3ae709: [GlobalISel] Add multi-way splitting support for w...

[Amara Emerson via All-commits]

  Branch: refs/heads/users/aemerson/split-shifts
  Home:   https://github.com/llvm/llvm-project
  Commit: 3ae7094e9cf9f68dc5b4a20bf8c495fd3d7eaf92
      https://github.com/llvm/llvm-project/commit/3ae7094e9cf9f68dc5b4a20bf8c495fd3d7eaf92
  Author: Amara Emerson <amara at apple.com>
  Date:   2025-08-25 (Mon, 25 Aug 2025)

  Changed paths:
    M llvm/include/llvm/CodeGen/GlobalISel/LegalizerHelper.h
    M llvm/lib/CodeGen/GlobalISel/LegalizerHelper.cpp
    A llvm/test/CodeGen/AArch64/GlobalISel/split-wide-shifts-multiway.ll
    M llvm/test/CodeGen/RISCV/GlobalISel/wide-scalar-shift-by-byte-multiple-legalization.ll

  Log Message:
  -----------
  [GlobalISel] Add multi-way splitting support for wide scalar shifts.

This patch implements direct N-way splitting for wide scalar shifts instead
of recursive binary splitting. For example, an i512 G_SHL can now be split
directly into 8 i64 operations rather than going through i256 -> i128 -> i64.

The main motivation behind this is to alleviate (although not entirely fix)
pathological compile time issues with huge types, like i4224. The problem
we see is that the recursive splitting strategy combined with our messy
artifact combiner ends up with terribly long compiles as tons of intermediate
artifacts are generated, and then attempted to be combined ad-nauseum.

Going directly from the large shifts to the destination types short-circuits
a lot of these issues, but it's still an abuse of the backend and front-ends
should never be doing this sort of thing.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications