[all-commits] [llvm/llvm-project] 544a6a: [InstCombine] combineLoadToOperationType(): don't ...

[Roman Lebedev via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 544a6aa2674e3875e4014eafb101a982f9296439
      https://github.com/llvm/llvm-project/commit/544a6aa2674e3875e4014eafb101a982f9296439
  Author: Roman Lebedev <lebedev.ri at gmail.com>
  Date:   2020-10-11 (Sun, 11 Oct 2020)

  Changed paths:
    M clang/test/CodeGen/arm64_32-vaarg.c
    M llvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp
    M llvm/test/Transforms/InstCombine/PR30597.ll
    M llvm/test/Transforms/InstCombine/intptr1.ll
    M llvm/test/Transforms/InstCombine/load-bitcast32.ll
    M llvm/test/Transforms/InstCombine/load-bitcast64.ll
    M llvm/test/Transforms/InstCombine/memset_chk-1.ll

  Log Message:
  -----------
  [InstCombine] combineLoadToOperationType(): don't fold int<->ptr cast into load

And another step towards transforms not introducing inttoptr and/or
ptrtoint casts that weren't there already.

As we've been establishing (see D88788/D88789), if there is a int<->ptr cast,
it basically must stay as-is, we can't do much with it.

I've looked, and the most source of new such casts being introduces,
as far as i can tell, is this transform, which, ironically,
tries to reduce count of casts..

On vanilla llvm test-suite + RawSpeed, @ `-O3`, this results in
-33.58% less `IntToPtr`s (19014 -> 12629)
and +76.20% more `PtrToInt`s (18589 -> 32753),
which is an increase of +20.69% in total.

However just on RawSpeed, where i know there are basically
none `IntToPtr` in the original source code,
this results in -99.27% less `IntToPtr`s (2724 -> 20)
and +82.92% more `PtrToInt`s (4513 -> 8255).
which is again an increase of 14.34% in total.

To me this does seem like the step in the right direction,
we end up with strictly less `IntToPtr`, but strictly more `PtrToInt`,
which seems like a reasonable trade-off.

See https://reviews.llvm.org/D88860 / https://reviews.llvm.org/D88995
for some more discussion on the subject.

(Eventually, `CastInst::isNoopCast()`/`CastInst::isEliminableCastPair`
should be taught about this, yes)

Reviewed By: nlopes, nikic

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