[PATCH] D115244: [LICM] Promote conditional, loop-invariant memory accesses to scalars

[Dimitrije Milošević via Phabricator via llvm-commits]

dmilosevic141 created this revision.
dmilosevic141 added a reviewer: djtodoro.
Herald added subscribers: asbirlea, hiraditya.
dmilosevic141 requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Promotion of conditional accesses (if there are no abnormal loop exits) was proposed here: Missed opportunities for register promotion <https://bugs.llvm.org/show_bug.cgi?id=51193#c1>. This patch covers the second proposed potential optimization - sinking the store instructions while making sure they are executed conditionally, depending on whether or not the value was written to.
Promotion of conditional accesses breaks the safety property, which divides into two parts:

- The memory may not be dereferencable on loop entry. In this case, we cannot hoist load instructions into the preheader basic block.
- The memory model does not allow us to insert a store along any dynamic path which did not originally have one.

The //LICM// pass, as of D113289 <https://reviews.llvm.org/D113289>, hoists load instructions which are not guaranteed to execute into the preheader basic block, if the memory proves to be dereferencable on loop entry. Note that this change **does not** sink the store instructions which are not guaranteed to execute into the exit blocks.
Sinking the store instructions, which are not guaranteed to execute, directly breaks the second part of the safety property mentioned above. To be more precise, sinking conditional store instructions may introduce data races/traps. In order to make it thread-safe, we need to make sure the sunken store instructions are executed conditionally, depending on whether or not the value was written to.
Consider the following source code:

  int u;
  
  void f(int a[restrict], int n)
  {
  	for (int i = 0; i < n; ++i)
  		if (a[i])
  			++u;
  }

This patch allows the //LICM// pass, in order for it to promote the conditional access of //u// (which would include hoisting the load instruction and sinking the store instruction), to insert a simple flag, which is initially (in the preheader) down. Whenever the control flow gets to the conditional store to //u//, the flag is raised. Finally, the sunken store instruction is executed conditionally in the exit blocks, depending on whether or not the flag was raised.
For the source code given above, the //LICM// pass, now, produces the following //LLVM IR// code (only the relevant parts are shown):

  ...
  entry:
    %u.promoted = load i32, i32* @u ...
    br label %for.cond
  for.cond:
    %u.flag4 = phi i8 [ 0, %entry ], [ %u.flag, %for.inc ] ; Note that the flag is down, if we get here through the preheader basic block.
    %inc3 = phi i32 [ %u.promoted, %entry ], [ %inc2, %for.inc ]
    ...
  for.body: 
  ...
  if.then:
    %inc = add nsw i32 %inc3, 1
    br label %for.inc
  for.inc:
    %u.flag = phi i8 [ 1, %if.then ], [ %u.flag4, %for.body ] ; Note that the flag is raised, if we get here through the if.then basic block.
    %inc2 = phi i32 [ %inc, %if.then ], [ %inc3, %for.body ]
    ...
  for.cond.cleanup: ; This is the only exit block.
    %u.flag4.lcssa = phi i8 [ %u.flag4, %for.cond ] ; Get the flag value.
    %inc3.lcssa = phi i32 [ %inc3, %for.cond ]
    %tobool.u.flag = icmp eq i8 %u.flag4.lcssa, 1
    br i1 %tobool.u.flag, label %u.flag.then.bb, label %u.flag.else.bb ; Skip the sunken store instruction, if the flag was never raised.
  u.flag.then.bb:
    store i32 %inc3.lcssa, i32* @u ...
    br label %u.flag.else.bb
  u.flag.else.bb:
    ret void
  }
  ...




Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D115244

Files:
  llvm/lib/Transforms/Scalar/LICM.cpp
  llvm/test/Transforms/LICM/conditional-access-promotion.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D115244.392345.patch
Type: text/x-patch
Size: 15637 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20211207/5ed4a326/attachment.bin>