[all-commits] [llvm/llvm-project] ee2f9d: Reapply [InstCombine] Remove early constant fold

[Nikita Popov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: ee2f9d6dfb6f1360d2dc68d151c84e80252a40ec
      https://github.com/llvm/llvm-project/commit/ee2f9d6dfb6f1360d2dc68d151c84e80252a40ec
  Author: Nikita Popov <npopov at redhat.com>
  Date:   2023-02-27 (Mon, 27 Feb 2023)

  Changed paths:
    M llvm/lib/Transforms/InstCombine/InstCombineCasts.cpp
    M llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
    M llvm/test/Transforms/InstCombine/pr38677.ll

  Log Message:
  -----------
  Reapply [InstCombine] Remove early constant fold

The reported compile-time regression has been address in
47f9109dff80a1abbe2705ee71dc0882b1d62274.

Additionally, this contains a change to immediately fold zext
with constant operand, even if it's used in a trunc. I'm not sure
if this is relevant for anything, but I noticed it as a behavioral
discrepancy when investigating this issue.

-----

InstCombine currently performs a constant folding attempt as part
of the main InstCombine loop, before visiting the instruction.
However, each visit method will also attempt to simplify the
instruction, which will in turn constant fold it. (Additionally,
we also constant fold instructions before the main InstCombine loop
and use a constant folding IR builder, so this is doubly redundant.)

There is one place where InstCombine visit methods currently don't
call into simplification, and that's casts. To be conservative,
I've added an explicit constant folding call there (though it has
no impact on tests).

This makes for a mild compile-time improvement and in particular
mitigates the compile-time regression from enabling load
simplification in be88b5814d9efce131dbc0c8e288907e2e6c89be.

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