This is an archive of the discontinued LLVM Phabricator instance.

[ModuloSchedule] Peel out prologs and epilogs, generate actual code
ClosedPublic

Authored by jmolloy on Sep 30 2019, 3:51 AM.

Details

Summary

This extends the PeelingModuloScheduleExpander to generate prolog and epilog code,
and correctly stitch uses through the prolog, kernel, epilog DAG.

The key concept in this patch is to ensure that all transforms are *local*; only a
function of a block and its immediate predecessor and successor. By defining the problem in this way
we can inductively rewrite the entire DAG using only local knowledge that is easy to
reason about.

For example, we assume that all prologs and epilogs are near-perfect clones of the
steady-state kernel. This means that if a block has an instruction that is predicated out,
we can redirect all users of that instruction to that equivalent instruction in our
immediate predecessor. As all blocks are clones, every instruction must have an equivalent in
every other block.

Similarly we can make the assumption by construction that if a value defined in a block is used
outside that block, the only possible user is its immediate successors. We maintain this
even for values that are used outside the loop by creating a limited form of LCSSA.

This code isn't small, but it isn't complex.

Enabled a bunch of testing from Hexagon. There are a couple of tests not enabled yet;
I'm about 80% sure there isn't buggy codegen but the tests are checking for patterns
that we don't produce. Those still need a bit more investigation. In the meantime we
(Google) are happy with the code produced by this on our downstream SMS implementation,
and believe it generates correct code.

Diff Detail

Repository
rL LLVM

Event Timeline

jmolloy created this revision.Sep 30 2019, 3:51 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 30 2019, 3:51 AM
ThomasRaoux added inline comments.Sep 30 2019, 9:17 PM
llvm/lib/CodeGen/ModuloSchedule.cpp
1612–1613 ↗(On Diff #222385)

I think one problem I was running into with this way of generating the epilogue is that instructions of phase 2 will depend of instruction from phase 1 with a distance of 1. So when we peel E0 the phase 2 is using value from phase 1 of K but then when we peel E1 instructions from phase 2 gets a wrong dependency.

Basically the kernel loop like:

K:
%a1 = phi (%ai, %a0)
InstPhase2 %a1
%a0 = InstPhase1
br K:

when we peel
K:
%a1 = phi (%ai, %a0)
InstPhase2 %a1
%a0 = InstPhase1;
br p K, E0:
E0:
InstPhase2 %a0
E1:
InstPhase2 ?
%a2 = InstPhase1

How do we handle that?

Hi Thomas,

I made an example to show how this is handled.

%11:intregs = S2_addasl_rrri %7, %6, 1, post-instr-symbol <mcsymbol Stage-0_Cycle-0>
%12:intregs = L2_loadruh_io %11, -4, post-instr-symbol <mcsymbol Stage-1_Cycle-0> :: (load 2 from %ir.cgep2, !tbaa !0)
%5:intregs = S2_storerh_pi %6, -2, %12, post-instr-symbol <mcsymbol Stage-2_Cycle-0> :: (store 2 into %ir.lsr.iv, !tbaa !0)
ENDLOOP0 %bb.3, implicit-def $pc, implicit-def $lc0, implicit $sa0, implicit $lc0

We generate this code, annotated:

 <... prolog, boring ...>

bb.3.b2 (address-taken):  // Kernel.
  successors: %bb.3(0x7c000000), %bb.10(0x04000000)

  %15:intregs = PHI %25, %bb.6, %11, %bb.3
  %17:intregs = PHI %26, %bb.6, %12, %bb.3
  %11:intregs = S2_addasl_rrri %7, %6, 1, post-instr-symbol <mcsymbol Stage-0_Cycle-0>
  %12:intregs = L2_loadruh_io %15, -4, post-instr-symbol <mcsymbol Stage-1_Cycle-0> :: (load 2 from %ir.cgep2, !tbaa !0)
  dead %5:intregs = S2_storerh_pi %6, -2, %17, post-instr-symbol <mcsymbol Stage-2_Cycle-0> :: (store 2 into %ir.lsr.iv, !tbaa !0)
  ENDLOOP0 %bb.3, implicit-def $pc, implicit-def $lc0, implicit $sa0, implicit $lc0
  J2_jump %bb.10, implicit-def $pc

bb.10.b2:  // Epilog 0, runs stage 2
  successors: %bb.9(0x80000000)

  %40:intregs = PHI %11, %bb.3, %25, %bb.6
  %41:intregs = PHI %12, %bb.3, %26, %bb.6
  dead %44:intregs = S2_storerh_pi %6, -2, %41, post-instr-symbol <mcsymbol Stage-2_Cycle-0> :: (store 2 into %ir.lsr.iv, !tbaa !0)
  J2_jump %bb.9, implicit-def $pc

bb.9.b2:  // Start of Epilog 1, runs stage 1
  successors: %bb.8(0x80000000)

  %35:intregs = PHI %40, %bb.10, %20, %bb.5
  %38:intregs = L2_loadruh_io %35, -4, post-instr-symbol <mcsymbol Stage-1_Cycle-0> :: (load 2 from %ir.cgep2, !tbaa !0)
  J2_jump %bb.8, implicit-def $pc

bb.8.b2:  // Next stage of Epilog 1, runs stage 2
  successors: %bb.7(0x80000000)

  dead %34:intregs = S2_storerh_pi %6, -2, %38, post-instr-symbol <mcsymbol Stage-2_Cycle-0> :: (store 2 into %ir.lsr.iv, !tbaa !0)
  J2_jump %bb.7, implicit-def $pc

The key is that though E1 runs stages {1,2}, we *don't* create a block with both stages {1,2} enabled. This would cause the invalid code issue you mentioned. Instead, we expand this into *two* blocks. The first performs stage 1, the second stage 2 which consumes its input from stage 1.

That means we do generate superfluous epilog blocks, but these get merged by the control flow optimizer later.

That said, I'm not guaranteeing there are no bugs here. Perhaps the testcase you're thinking of distills to something more complex than my testcase?

Cheers,

James

ThomasRaoux accepted this revision.Oct 1 2019, 9:37 AM

Hi Thomas,

I made an example to show how this is handled.

%11:intregs = S2_addasl_rrri %7, %6, 1, post-instr-symbol <mcsymbol Stage-0_Cycle-0>
%12:intregs = L2_loadruh_io %11, -4, post-instr-symbol <mcsymbol Stage-1_Cycle-0> :: (load 2 from %ir.cgep2, !tbaa !0)
%5:intregs = S2_storerh_pi %6, -2, %12, post-instr-symbol <mcsymbol Stage-2_Cycle-0> :: (store 2 into %ir.lsr.iv, !tbaa !0)
ENDLOOP0 %bb.3, implicit-def $pc, implicit-def $lc0, implicit $sa0, implicit $lc0

We generate this code, annotated:

 <... prolog, boring ...>

bb.3.b2 (address-taken):  // Kernel.
  successors: %bb.3(0x7c000000), %bb.10(0x04000000)

  %15:intregs = PHI %25, %bb.6, %11, %bb.3
  %17:intregs = PHI %26, %bb.6, %12, %bb.3
  %11:intregs = S2_addasl_rrri %7, %6, 1, post-instr-symbol <mcsymbol Stage-0_Cycle-0>
  %12:intregs = L2_loadruh_io %15, -4, post-instr-symbol <mcsymbol Stage-1_Cycle-0> :: (load 2 from %ir.cgep2, !tbaa !0)
  dead %5:intregs = S2_storerh_pi %6, -2, %17, post-instr-symbol <mcsymbol Stage-2_Cycle-0> :: (store 2 into %ir.lsr.iv, !tbaa !0)
  ENDLOOP0 %bb.3, implicit-def $pc, implicit-def $lc0, implicit $sa0, implicit $lc0
  J2_jump %bb.10, implicit-def $pc

bb.10.b2:  // Epilog 0, runs stage 2
  successors: %bb.9(0x80000000)

  %40:intregs = PHI %11, %bb.3, %25, %bb.6
  %41:intregs = PHI %12, %bb.3, %26, %bb.6
  dead %44:intregs = S2_storerh_pi %6, -2, %41, post-instr-symbol <mcsymbol Stage-2_Cycle-0> :: (store 2 into %ir.lsr.iv, !tbaa !0)
  J2_jump %bb.9, implicit-def $pc

bb.9.b2:  // Start of Epilog 1, runs stage 1
  successors: %bb.8(0x80000000)

  %35:intregs = PHI %40, %bb.10, %20, %bb.5
  %38:intregs = L2_loadruh_io %35, -4, post-instr-symbol <mcsymbol Stage-1_Cycle-0> :: (load 2 from %ir.cgep2, !tbaa !0)
  J2_jump %bb.8, implicit-def $pc

bb.8.b2:  // Next stage of Epilog 1, runs stage 2
  successors: %bb.7(0x80000000)

  dead %34:intregs = S2_storerh_pi %6, -2, %38, post-instr-symbol <mcsymbol Stage-2_Cycle-0> :: (store 2 into %ir.lsr.iv, !tbaa !0)
  J2_jump %bb.7, implicit-def $pc

The key is that though E1 runs stages {1,2}, we *don't* create a block with both stages {1,2} enabled. This would cause the invalid code issue you mentioned. Instead, we expand this into *two* blocks. The first performs stage 1, the second stage 2 which consumes its input from stage 1.

That means we do generate superfluous epilog blocks, but these get merged by the control flow optimizer later.

That said, I'm not guaranteeing there are no bugs here. Perhaps the testcase you're thinking of distills to something more complex than my testcase?

Cheers,

James

Thanks for explaining. That makes sense, I missed that we peel the two phases in two steps. I wonder if there is a way to express it easily in the comment. Anyway it looks like it works, I think the case I saw was the same pattern so it should work.

This revision is now accepted and ready to land.Oct 1 2019, 9:37 AM
This revision was automatically updated to reflect the committed changes.
RKSimon added a subscriber: RKSimon.Oct 3 2019, 8:09 AM

@jmolloy This is failing on EXPENSIVE_CHECKS builds - please can you take a look ?

http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/19970/