[llvm] [MachinePipeliner] Add an abstract layer to manipulate Data Dependenc… (PR #109918)

via llvm-commits llvm-commits at lists.llvm.org
Mon Oct 21 11:47:57 PDT 2024


dpenry wrote:

> My guess remains the same as before. That is, I think the handling of these anti-dependencies looks unintentional to me. If loop-carried physical register dependencies are to be handled correctly, at least the following must also be considered (but are not now).
> 
>     * Not only anti-dependencies, but also data-dependencies and output-dependencies need to be taken into account
> 
>     * If there are multiple WAR dependencies of the same physical register, the current checks are insufficient
>       
>       * Example: https://godbolt.org/z/6vqKMb5TK
>         
>         * This is neither a loop nor SSA form, but this type of physical register dependencies can occur in MachinePipeliner
>       * There is a loop-carried dependence between SU(3) and SU(0), but it is not handled
> 
> 

Physical register dependency support is not unintentional, just not widely used and somewhat under-tested because software pipelining is enabled for only a handful of architectures and the first ones for which it was used supported decrement-and-branch instructions.  When I added support for SMS for ARM and had to support using normal conditional branches using the condition codes, I had to insert some special cases for physical registers because some dependences were not being respected.  See the comments in dcb77643e3440e948010ed8ecb4c2f8fe4fadb93.

I'm not sure what the godbolt link you've supplied is supposed to show, as there isn't a loop, so you can't say anything about whether loop-carried dependences are handled correctly.  The proper output and anti-dependencies for the MIR are present in the data graph.  One might argue that an anti-dependence between SU(1) and SU(4) is missing, but the anti-dependence from 1->2 combined with the output dependence from 2->4 make it unnecessary, and I think the DDG builder might notice that.


https://github.com/llvm/llvm-project/pull/109918


More information about the llvm-commits mailing list