[all-commits] [llvm/llvm-project] 283f5a: [GlobalISel] Fix incorrect sign extension when com...

[Lucas Duarte Prates via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 283f5a198a0e3c9978ca426e64a3011b566c2581
      https://github.com/llvm/llvm-project/commit/283f5a198a0e3c9978ca426e64a3011b566c2581
  Author: Lucas Prates <lucas.prates at arm.com>
  Date:   2022-01-20 (Thu, 20 Jan 2022)

  Changed paths:
    M llvm/include/llvm/CodeGen/GlobalISel/CombinerHelper.h
    M llvm/include/llvm/CodeGen/GlobalISel/MIPatternMatch.h
    M llvm/include/llvm/Target/GlobalISel/Combine.td
    M llvm/lib/CodeGen/GlobalISel/CombinerHelper.cpp
    M llvm/test/CodeGen/AArch64/GlobalISel/combine-ptradd-int2ptr.mir
    A llvm/test/CodeGen/AArch64/GlobalISel/inttoptr_add.ll

  Log Message:
  -----------
  [GlobalISel] Fix incorrect sign extension when combining G_INTTOPTR and G_PTR_ADD

The GlobalISel combiner currently uses sign extension when manipulating
the LHS constant when combining a sequence of the following sequence of
machine instructions into a single constant:
```
  %0:_(s32) = G_CONSTANT i32 <CONSTANT>
  %1:_(p0) = G_INTTOPTR %0:_(s32)
  %2:_(s64) = G_CONSTANT i64 <CONSTANT>
  %3:_(p0) = G_PTR_ADD %1:_, %2:_(s64)
```

This causes an issue when the bit width of the first contant and the
target pointer size are different, as G_INTTOPTR has no sign extension
semantics.

This patch fixes this by capture an arbitrary precision in when matching
the constant, allowing the matching function to correctly zero extend
it.

Reviewed By: arsenm

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