[llvm-dev] sret read after unwind

[Philip Reames via llvm-dev]

I ran across something a bit similar, and thought I'd share the case for 
purposes of idea generation.

For a function w/out-params, it's common to have cases where the 
out-params are not actually used by the callee.  I've recently been 
making some improvements for the cases where the out-param is the only 
thing holding the call live (D115829), but if we actually use the return 
value, we're left with a dead write (inside the callee) which we can't 
seem to eliminate without inlining.

As an example:

declare i1 @callee(i32* %out) {
   store i32 1, i32* %out
   ret i1 true
}

declare void @test() {
   %a = alloca i32
    %res = call i1 @callee(i32* %a)
    call void @use(%res)
}

If we had similar in spirit to your "nounwindread" but applied to the 
normal return path (e.g. "noreadonreturn"), we could in principal 
leverage this to simplify the callee.  DSE has all the information today 
to annotate "noreadonreturn" arguments at the call site.  We could have 
an IPO transform which merges the information from all callees, and 
drops the writes.  (We could also e.g. specialize if not all had the 
param as dead.)

This particular case isn't strongly motivated enough to bother building 
out infrastructure for, but it's interesting that another somewhat 
analogous use case has popped up.

Philip

On 12/4/21 2:39 AM, Nikita Popov via llvm-dev wrote:
> Hi,
>
> Consider the following IR:
>
> declare void @may_unwind()
> define void @test(i32* noalias sret(i32) %out) {
>     store i32 0, i32* %out
>     call void @may_unwind()
>     store i32 1, i32* %out
>     ret void
> }
>
> Currently, we can't remove the first store as dead, because the 
> @may_unwind() call may unwind, and the caller might read %out at that 
> point, making the first store visible.
>
> Similarly, it prevents call slot optimization in the following 
> example, because the call may unwind and make an early write to the 
> sret argument visible:
>
> declare void @may_unwind(i32*)
> declare void @llvm.memcpy.p0i8.p0i8.i64(i8*, i8*, i64, i1)
> define void @test(i32* noalias sret(i32) %arg) {
>     %tmp = alloca i32
>     call void @may_unwind(i32* nocapture %tmp)
>     %tmp.8 = bitcast i32* %tmp to i8*
>     %arg.8 = bitcast i32* %arg to i8*
>     call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 4 %arg.8, i8* align 
> 4 %tmp.8, i64 4, i1 false)
>     ret void
> }
>
> I would like to address this in some form. The easiest way would be to 
> change LangRef to specify that sret arguments cannot be read on unwind 
> paths. I think that matches how sret arguments are generally used.
>
> Alternatively, this could be handled using a separate attribute that 
> can be applied to any argument, something along the lines of "i32* 
> nounwindread sret(i32) %arg". The benefit would be that this is 
> decoupled from sret ABI semantics and could potentially be inferred 
> (e.g. if the function is only ever used with call and not invoke, this 
> should be a given).
>
> Any thoughts on this? Is this a problem worth solving, and if yes, 
> would a new attribute be preferred over restricting sret semantics?
>
> Regards,
> Nikita
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211216/9a1353ce/attachment.html>