[PATCH] D50925: [LICM] Hoist stores of invariant values to invariant addresses out of loops

[Anna Thomas via Phabricator via llvm-commits]

anna added a comment.

In https://reviews.llvm.org/D50925#1211359, @reames wrote:

> In https://reviews.llvm.org/D50925#1211015, @anna wrote:
>
> > There are 3 kinds of tests worth adding:
> >
> > 1. predicated invariant stores, i.e. the block containing the store itself is predicated and not guaranteed to execute (cannot be handled by LICM)
>
>
> Covered by existing early exit test.
>
> > 2. invariant store value is a phi containing invariant incoming values and the phi result depends on an invariant condition (can be handled by LICM. This patch handles?)
>
> Unclear what you mean here.


Added example:

  define void @inv_val_store_to_inv_address_conditional_inv(i32* %a, i64 %n, i32* %b, i32 %k) {
  entry:
    %ntrunc = trunc i64 %n to i32
    %cmp = icmp eq i32 %ntrunc, %k
    br label %for.body
  
  for.body:                                         ; preds = %for.body, %entry
    %i = phi i64 [ %i.next, %latch ], [ 0, %entry ]
    %tmp1 = getelementptr inbounds i32, i32* %b, i64 %i
    %tmp2 = load i32, i32* %tmp1, align 8
    store i32 %ntrunc, i32* %tmp1
    br i1 %cmp, label %cond_store, label %cond_store_k
  
  cond_store:
    br label %latch
  
  cond_store_k:
    br label %latch
  
  latch:
    %storeval = phi i32 [ %ntrunc, %cond_store ], [ %k, %cond_store_k ]
    store i32 %storeval, i32* %a <-- this store can be hoisted by LICM (the stored value is invariant in the loop). 
    %i.next = add nuw nsw i64 %i, 1
    %cond = icmp slt i64 %i.next, %n
    br i1 %cond, label %for.body, label %for.end
  
  for.end:                                          ; preds = %for.body
    ret void

>> 3. invariant store value is a phi containing  invariant incoming values and the phi result depends on a variant condition (cannot be handled by LICM safely)
> 
> Again, I don't know what you mean by this.  If the value is a phi in the loop, it's by definition not invariant.

yes, that's why I stated it "cannot be handled by LICM safely", in the sense it is not correct :)


https://reviews.llvm.org/D50925