[all-commits] [llvm/llvm-project] 08b3c0: [GlobalISel] Combine G_UMULH x, (1 << c)) -> x >> ...

Amara Emerson via All-commits all-commits at lists.llvm.org
Thu Oct 7 23:51:50 PDT 2021


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 08b3c0d995d83060ae0cf3d3b2f9936da380cf29
      https://github.com/llvm/llvm-project/commit/08b3c0d995d83060ae0cf3d3b2f9936da380cf29
  Author: Amara Emerson <amara at apple.com>
  Date:   2021-10-07 (Thu, 07 Oct 2021)

  Changed paths:
    M llvm/include/llvm/CodeGen/GlobalISel/CombinerHelper.h
    M llvm/include/llvm/CodeGen/GlobalISel/Utils.h
    M llvm/include/llvm/Target/GlobalISel/Combine.td
    M llvm/lib/CodeGen/GlobalISel/CSEMIRBuilder.cpp
    M llvm/lib/CodeGen/GlobalISel/CombinerHelper.cpp
    M llvm/lib/CodeGen/GlobalISel/Utils.cpp
    M llvm/test/CodeGen/AArch64/GlobalISel/combine-udiv.ll
    M llvm/test/CodeGen/AArch64/GlobalISel/combine-udiv.mir
    A llvm/test/CodeGen/AArch64/GlobalISel/combine-umulh-to-lshr.mir
    M llvm/test/CodeGen/AMDGPU/GlobalISel/udiv.i32.ll
    M llvm/test/CodeGen/AMDGPU/GlobalISel/udiv.i64.ll
    M llvm/unittests/CodeGen/GlobalISel/CSETest.cpp

  Log Message:
  -----------
  [GlobalISel] Combine G_UMULH x, (1 << c)) -> x >> (bitwidth - c)

In order to not generate an unnecessary G_CTLZ, I extended the constant folder
in the CSEMIRBuilder to handle G_CTLZ. I also added some extra handing of
vector constants too. It seems we don't have any support for doing constant
folding of vector constants, so the tests show some other useless G_SUB
instructions too.

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


  Commit: 72ce310bf0deceea6929eebbfc0d65e799d86ad9
      https://github.com/llvm/llvm-project/commit/72ce310bf0deceea6929eebbfc0d65e799d86ad9
  Author: Amara Emerson <amara at apple.com>
  Date:   2021-10-07 (Thu, 07 Oct 2021)

  Changed paths:
    M llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp

  Log Message:
  -----------
  [GlobalISel][IRTranslator] Fix a use-after-free bug when translating trap-func-name traps.

This was using MachineFunction::createExternalSymbolName() before, which seems
reasonable, but in fact this is freed before the asm emitter which tries to access
the function name string. Switching it to use the string returned by the attribute
seems to fix the problem.


Compare: https://github.com/llvm/llvm-project/compare/23800b05be2b...72ce310bf0de


More information about the All-commits mailing list