[PATCH] D95672: [LV] Vectorize backward dependence

Hu Jiangping via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Mar 17 19:52:53 PDT 2021


hujp added a comment.

Hi fhahn! I have update the patch according to your comment No.2. For the others, here are our considerations.

In D95672#2617780 <https://reviews.llvm.org/D95672#2617780>, @fhahn wrote:

> 1. Can the initial patch be focused on initial support and only handle the case where only pairs of instructions need to be moved before/after another, not a list of instructions needs to be moved before/after another instruction?

The instruction we really want to move is a load or a store, but the instruction that needs to be moved is usually not a single instruction, at least including the operands of it. In addition, the instructions in front of them that access the same array may also need to be moved, so that the access order of the same element remains unchanged after moving, and there will be no new backward type dependency for different elements. Therefore, it is not representative to move only one instruction, so we consider moving a list.

> 3. Can we just use AliasAnalysis to check for instructions that block moving?

We refer to the existing processing of `LoopAccessInfo` for the processing of finding aliases. By looking for aliases, we want to find all the instructions that need to be moved together, which, of course, may block moving. But there's something else may block moving.

> 4. Why do we need to handle `EnableForwardingConflictDetection` again? Could LAI remember/mark those dependences, so we do not need to re-check them?

`EnableForwardingConflictDetection` was handled in `MemoryDepChecker::isDependent`, before that, if the dependency is backward, then the processing has returned. So when we analyze backward dependency, as a supplement, we also need to handle `EnableForwardingConflictDetection`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D95672/new/

https://reviews.llvm.org/D95672



More information about the llvm-commits mailing list