[all-commits] [llvm/llvm-project] 96843d: [AArch64][GlobalISel] Change G_ANYEXT fed by scala...

[Jessica Paquette via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 96843d220dd8cf10ef5e67b8bdb0205d6bb9d7f7
      https://github.com/llvm/llvm-project/commit/96843d220dd8cf10ef5e67b8bdb0205d6bb9d7f7
  Author: Jessica Paquette <jpaquette at apple.com>
  Date:   2021-10-01 (Fri, 01 Oct 2021)

  Changed paths:
    M llvm/lib/Target/AArch64/AArch64Combine.td
    M llvm/lib/Target/AArch64/GISel/AArch64PostLegalizerCombiner.cpp
    A llvm/test/CodeGen/AArch64/GlobalISel/postlegalizer-combiner-anyext-to-zext.mir

  Log Message:
  -----------
  [AArch64][GlobalISel] Change G_ANYEXT fed by scalar G_ICMP to G_ZEXT

This is a common pattern:

```
    %icmp:_(s32) = G_ICMP intpred(eq), ...
    %ext:_(s64) = G_ANYEXT %icmp(s32)
    %and:_(s64) = G_AND %ext, 1
```

Here's an example: https://godbolt.org/z/T13f6o8zE

This pattern appears because of the following combine in the
LegalizationArtifactCombiner:

```
// zext(trunc x) - > and (aext/copy/trunc x), mask
```

Which kicks in when we widen the result of G_ICMP from 1 bit to 32 bits.

We know that, on AArch64, a scalar G_ICMP will produce 0 or 1. So the result
of `%ext` will always be 0 or 1 as well.

We have some KnownBits combines which eliminate redundant G_ANDs with masks.
These combines don't kick in with G_ANYEXT.

So, if we replace the G_ANYEXT with G_ZEXT in this situation, the KnownBits
based combines can remove the redundant G_AND.

I wasn't sure if it woud be more appropriate to

* Take this route
* Put this in the LegalizationArtifactCombiner.
* Allow 64 bit G_ICMP destinations

I decided on this route because

1) It's simple

2) I'm not sure if philosophically-speaking, we should be handling non-artifact
instructions + target-specific details like TargetBooleanContents in the
LegalizationArtifactCombiner

3) There is a lot of existing code which assumes we only have 32 bit G_ICMP
destinations. So, adding support for 64-bit destinations seems rather invasive
right now. I think that adding support for 64-bit destinations, or modelling
G_ICMP as ADDS/SUBS/etc is probably cleaner long term though.

This gives minor code size savings on all CTMark benchmarks.

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