Not DSEing of stores to aggregates arguments

[pinskia]

Take:

struct f
{
  int a[1024];
};
struct f h(struct f a1)
{
  struct f a = {};
  a1 = a;
  return a;
}

There should only be 1 memset (zeroing) in the function h.

[pinskia]

This might be a dup of #4113; it is at least related to it.

Note GCC is able to do only one memset.

[frederick-vs-ja]

It seems that Clang achieved the desired optimizations in Clang 3.7 (demo). Is there anything still missing?

[pinskia]

Yes I was testing with aarch64 rather than X86_64.

[frederick-vs-ja]

Looks like that Clang emitted redundant llvm.memset.p0.i64 on AArch64 (demo).

LLVM-IR

AArch64:

%struct.f = type { [1024 x i32] }

define dso_local void @h(ptr dead_on_unwind noalias writable writeonly sret(%struct.f) align 4 captures(none) initializes((0, 4096)) %0, ptr noundef writeonly captures(none) initializes((0, 4096)) %1) local_unnamed_addr #0 !dbg !10 {
    #dbg_value(ptr %1, !22, !DIExpression(DW_OP_deref), !24)
    #dbg_declare(ptr %0, !23, !DIExpression(), !25)
  tail call void @llvm.memset.p0.i64(ptr noundef nonnull align 4 dereferenceable(4096) %0, i8 0, i64 4096, i1 false), !dbg !25
  tail call void @llvm.memset.p0.i64(ptr noundef nonnull align 4 dereferenceable(4096) %1, i8 0, i64 4096, i1 false), !dbg !26
  ret void, !dbg !27
}

declare void @llvm.memset.p0.i64(ptr writeonly captures(none), i8, i64, i1 immarg) #1

attributes #0 = { mustprogress nofree norecurse nosync nounwind willreturn memory(argmem: write) uwtable "frame-pointer"="non-leaf" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="generic" "target-features"="+fp-armv8,+neon,+outline-atomics,+v8a,-fmv" }
attributes #1 = { mustprogress nocallback nofree nounwind willreturn memory(argmem: write) }

x86-64:

%struct.f = type { [1024 x i32] }

define dso_local void @h(ptr dead_on_unwind noalias writable writeonly sret(%struct.f) align 4 captures(none) initializes((0, 4096)) %0, ptr noundef readnone byval(%struct.f) align 8 captures(none) %1) local_unnamed_addr #0 !dbg !9 {
    #dbg_declare(ptr %1, !21, !DIExpression(), !23)
    #dbg_declare(ptr %0, !22, !DIExpression(), !24)
  tail call void @llvm.memset.p0.i64(ptr noundef nonnull align 4 dereferenceable(4096) %0, i8 0, i64 4096, i1 false), !dbg !24
  ret void, !dbg !25
}

declare void @llvm.memset.p0.i64(ptr writeonly captures(none), i8, i64, i1 immarg) #1

attributes #0 = { mustprogress nofree norecurse nosync nounwind willreturn memory(argmem: write) uwtable "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cmov,+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" }
attributes #1 = { mustprogress nocallback nofree nounwind willreturn memory(argmem: write) }

[llvmbot]

@llvm/issue-subscribers-clang-codegen

Author: Andrew Pinski (pinskia)

Take: ``` struct f { int a[1024]; }; struct f h(struct f a1) { struct f a = {}; a1 = a; return a; } ```

There should only be 1 memset (zeroing) in the function h.

[nikic]

I guess we're missing some attribute like dead_on_return for the argument. Or possibly noalias_move.

[antoniofrighetto]

I guess we're missing some attribute like dead_on_return for the argument. Or possibly noalias_move.

You mean introducing a new dead_on_return attribute here? I clearly miss some historical context, yet I wish we could somehow continue re-using byval on AArch64, even when it's the callee which creates the temporary (the LangRef says: «The attribute implies that a hidden copy of the pointee is made between the caller and the callee», but doesn't seem to be imply the copy has to be caller-made).

[nikic]

I guess we're missing some attribute like dead_on_return for the argument. Or possibly noalias_move.

You mean introducing a new dead_on_return attribute here?

Yes.

I clearly miss some historical context, yet I wish we could somehow continue re-using byval on AArch64, even when it's the callee which creates the temporary (the LangRef says: «The attribute implies that a hidden copy of the pointee is made between the caller and the callee», but doesn't seem to be imply the copy has to be caller-made).

There are two different ABIs: Both perform a copy, but in one case the pointer is passed explicitly as an argument, and in the other the copy is just located at a specific stack offset.

[antoniofrighetto]

I clearly miss some historical context, yet I wish we could somehow continue re-using byval on AArch64, even when it's the callee which creates the temporary (the LangRef says: «The attribute implies that a hidden copy of the pointee is made between the caller and the callee», but doesn't seem to be imply the copy has to be caller-made).

There are two different ABIs: Both perform a copy, but in one case the pointer is passed explicitly as an argument, and in the other the copy is just located at a specific stack offset.

I assume dead_on_return would be handling the second case here. As a consequence, it should be reasonable to say byval always imply dead_on_return.