[LLVMdev] Optimizing out redundant alloca involving byval params

[Reid Kleckner]

On Wed, Apr 1, 2015 at 5:32 PM, Mircea Trofin <mtrofin at google.com> wrote:

> I dug a bit more. It appears the succession -memcpyopt -instcombine can
> convert this:
>
> %struct.Str = type { i32, i32, i32, i32, i32, i32 }
>
> define void @_Z4test3Str(%struct.Str* byval align 8 %s) {
>
> entry:
>
>   %agg.tmp = alloca %struct.Str, align 8
>
>   %0 = bitcast %struct.Str* %agg.tmp to i8*
>
>   %1 = bitcast %struct.Str* %s to i8*
>
>   call void @llvm.memcpy.p0i8.p0i8.i64(i8* %0, i8* %1, i64 24, i32 4, i1
> false)
>
>   call void @_Z6e_test3Str(%struct.Str* byval align 8 %agg.tmp)
>
>   ret void
>
> }
>
> Into this:
>
> define void @_Z4test3Str(%struct.Str* byval align 8 %s) {
>
> entry:
>
>   call void @_Z6e_test3Str(%struct.Str* byval align 8 %s)
>
>   ret void
>
> }
>
>
> Which is great. This isn't however happening with a GEP and load/store -
> based IR (so a total of 6 sets of GEP on %s, load, then GEP on %agg.tmp +
> store , like the one discussed earlier in this thread).
>
> I see 2 options:
>
> 1) convert the pass I'm working on to produce memcpy instead of load/store
> successions, which would allow the resulting IR to fit in the canonical
> patterns optimized today, or
>
I'd say that if you are copying an object and it requires more than 2 loads
and stores, use memcpy. This is what Clang does for aggregate copies when
there is no copy ctor.

> 2) add support (probably to memcpyopt) for converting load/store
> successions into memcpy, then let the current optimizations reduce the
> resulting IR.
>
We should do this as a separate pass (I thought we did?), but it's hard to
do when there is interior padding in the struct. It's hard to know if the
interior padding of the destination needs to retain the data that was
originally there.


> I'm looking for feedback as to which path to take. Are there known
> instances of successive load/store that would benefit from being replaced
> with memcpy (option 2)?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150402/b73b4a38/attachment.html>