[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