[PATCH] D70210: [MirNamer][Canonicalizer]: Perform instruction semantic based renaming

[Aditya Nandakumar via Phabricator via llvm-commits]

aditya_nandakumar created this revision.
aditya_nandakumar added reviewers: bogner, plotfi.
Herald added subscribers: hiraditya, nhaehnle, jvesely.
Herald added a project: LLVM.
aditya_nandakumar added a subscriber: volkan.
aditya_nandakumar added a reviewer: volkan.
aditya_nandakumar removed a subscriber: volkan.

Previously:

- Due to sensitivity of the algorithm with gaps, and extra instructions, when diffing, often we see naming being off by a few. Makes the diff unreadable even for tests with 7 and 8 instructions respectively.
- Naming can change depending on candidates (and order of picking candidates). Suddenly if there's one extra instruction somewhere, the entire subtree would be named completely differently.
- No consistent naming of similar instructions which occur in different functions. If we try to do something like count the frequency distribution of various differences across suite, then the above sensitivity issues are going to result in poor results.

Instead:

- Name instruction based on semantics of the instruction (hash of the opcode and operands). Essentially for a given instruction that occurs in any module/function it'll be named similarly (ie semantic). This has some nice properties
  - Can easily look at many instructions and just check the hash and if they're named similarly, then it's the same instruction. Makes it very easy to spot the same instruction both multiple times, as well as across many functions (useful for frequency distribution).
  - Independent of traversal/candidates/depth of graph. No need to keep track of last index/gaps/skip count etc.
  - No off by few issues with diffs. I've tried the old vs new implementation in files ranging from 30 to 700 instructions. In both cases with the old algorithm, diffs are a sea of red, where as for the semantic version, in both cases, the diffs line up beautifully.
  - Simplified implementation of the main loop (simple iteration) , no keep track of what's visited and not.
- Handle collision just by incrementing a counter. Roughly bb[N]_hash_[CollisionCount].

Additionally with the new implementation, we can probably avoid doing the hoisting of instructions to various places, as they'll likely be named the same resulting in differences only based on collision (ie regardless of whether the instruction is hoisted or not/close to use or not, it'll be named the same hash which should result in use of the instruction be identical with the only change being the collision count) which is very easy to spot visually.


Repository:
  rL LLVM

https://reviews.llvm.org/D70210

Files:
  llvm/lib/CodeGen/MIRCanonicalizerPass.cpp
  llvm/lib/CodeGen/MIRVRegNamerUtils.cpp
  llvm/lib/CodeGen/MIRVRegNamerUtils.h
  llvm/test/CodeGen/MIR/AArch64/mirCanonCopyCopyProp.mir
  llvm/test/CodeGen/MIR/AArch64/mirCanonIdempotent.mir
  llvm/test/CodeGen/MIR/AArch64/mirnamer.mir
  llvm/test/CodeGen/MIR/AMDGPU/mir-canon-multi.mir

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D70210.229187.patch
Type: text/x-patch
Size: 29174 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20191113/18900a5c/attachment.bin>