[PATCH] D125485: [ArgPromotion] Unify byval promotion with non-byval

Pavel Samolysov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri May 13 01:27:09 PDT 2022


psamolysov added a comment.

@aeubanks Thank you for the comment. I'm not sure that I really get what "loaded by a later load" means, if it means any `load` instruction after the `store` in the same function, this case won't be optimized:

  define internal void @k(%struct.ss* byval(%struct.ss) align 4 %b) nounwind  {
  entry:
    %temp = getelementptr %struct.ss, %struct.ss* %b, i32 0, i32 0
    %temp1 = load i32, i32* %temp, align 4
    %temp2 = add i32 %temp1, 1
    store i32 %temp2, i32* %temp, align 4
    %temp3 = load i32, i32* %temp, align 4
    ret void
  }

because the check `AAR.canInstructionRangeModRef` (https://github.com/llvm/llvm-project/blob/main/llvm/lib/Transforms/IPO/ArgumentPromotion.cpp#L658) will return `true` that means the pointer was invalidated. If the `load` instruction takes place in another basic block, the `AAR.canBasicBlockModify(*TranspBB, Loc)` check will save us.

But I've found the new unified approach has a disadvantage from this point of view: when the original byval promotion restores the argument's structure in the callee and remains its users the same, the new approach just does nothing. So, when the original byval promotion gives room for the SROA optimization, the new scheme does not. The example above will be optimized into a single line with the `-sroa` pass after the "old" `-argpromotion` one:

  define internal void @k(i32 %b.0, i64 %b.1) #0 {
  entry:
    %temp2 = add i32 %b.0, 1
    ret void
  }

and will not be optimized at all with the `-sroa` pass after the "new" `-argpromotion` one.

Currently I have no idea how to restore the optimization room for SROA in that case.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D125485/new/

https://reviews.llvm.org/D125485



More information about the llvm-commits mailing list