[PATCH] D37034: Insert IMPLICIT_DEFS for undef uses in tail merging
Krzysztof Parzyszek via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Aug 23 10:17:54 PDT 2017
kparzysz added inline comments.
================
Comment at: lib/CodeGen/BranchFolding.cpp:379
+ LiveOuts.clear();
+ LiveOuts.addLiveOuts(*Pred);
----------------
kparzysz wrote:
> This needs to calculate liveouts with the tail removed.
>
> This testcase still fails:
>
> ```
> # RUN: llc -march=hexagon -run-pass branch-folder %s -o -
> ---
> name: fred
> tracksRegLiveness: true
>
> body: |
> bb.0:
> successors: %bb.1, %bb.2
> J2_jumpt undef %p0, %bb.2, implicit-def %pc
> J2_jump %bb.1, implicit-def %pc
>
> bb.1:
> successors: %bb.3
> %r1 = A2_tfrsi 1
> PS_storerhabs 0, undef %r0
> %r0 = A2_tfrsi 1
> J2_jump %bb.3, implicit-def %pc
>
> bb.2:
> successors: %bb.3
> %r0 = L2_loadruh_io undef %r1, 0
> PS_storerhabs 0, killed %r0
> %r0 = A2_tfrsi 1
> J2_jump %bb.3, implicit-def %pc
>
> bb.3:
> PS_jmpret killed %r31, implicit undef %r0, implicit-def %pc
> ...
> ```
>
> The output is
>
> ```
> body: |
> bb.0:
> successors: %bb.1(0x40000000), %bb.2(0x40000000)
>
> J2_jumpt undef %p0, %bb.2, implicit-def %pc
>
> bb.1:
> successors: %bb.3(0x80000000)
>
> %r1 = A2_tfrsi 1
> J2_jump %bb.3, implicit-def %pc
>
> bb.2:
> successors: %bb.3(0x80000000)
>
> %r0 = L2_loadruh_io undef %r1, 0
>
> bb.3:
> liveins: %r0
>
> PS_storerhabs 0, killed %r0
> %r0 = A2_tfrsi 1
> PS_jmpret killed %r31, implicit undef %r0, implicit-def %pc
>
> ...
> ```
>
> The path `bb.0` -> `bb.1` -> `bb.3` does not define `r0`, but `r0` is a live-in to `bb.3`.
In the original testcase, one of the blocks became the common tail. In this testcase, r1=... was added to that block to force a fresh block to be created for the tail. Then r0=... was added to both source blocks, but at the end so that it would be a part of the common tail. Because of how the live-outs in the code are calculated, this would prevent implicit defs from being added.
I had to change the order of the blocks to trigger the problem, since the traversal order for the predecessors may avoid exposing it.
Repository:
rL LLVM
https://reviews.llvm.org/D37034
More information about the llvm-commits
mailing list