llvm dev - Mar 2015 - [LLVMdev] Optimizing out redundant alloca involving byval params

Hello all,

I'm trying to find the pass that would convert from:

define void @main(%struct* byval %ptr) {
  %val = load %struct* %ptr
  %val.ptr = alloca %struct
  store %struct %val, %struct* %val.ptr
  call void @extern_func(%struct* byval %val.ptr)
  ret void
}

to this:
define void @main(%struct* byval %ptr) {
  call void @extern_func(%struct* byval %ptr)
  ret void
}

First, am I missing something - would this be a correct optimization?

Thank you,
Mircea.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150305/b270efd5/attachment.html>

I think lib/Transforms/Scalar/MemCpyOptimizer.cpp might be the right place
for this, considering that most frontends will use memcpy for that copy
anyway. It already has some logic for byval args.

On Thu, Mar 5, 2015 at 3:51 PM, Mircea Trofin <mtrofin at google.com>
wrote:
> Hello all,
>
> I'm trying to find the pass that would convert from:
>
> define void @main(%struct* byval %ptr) {
>   %val = load %struct* %ptr
>   %val.ptr = alloca %struct
>   store %struct %val, %struct* %val.ptr
>   call void @extern_func(%struct* byval %val.ptr)
>   ret void
> }
>
> to this:
> define void @main(%struct* byval %ptr) {
>   call void @extern_func(%struct* byval %ptr)
>   ret void
> }
>
> First, am I missing something - would this be a correct optimization?
>
> Thank you,
> Mircea.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150305/c0a460a6/attachment.html>

Reid is right that this would go in memcpyopt, but... we there's an 
active discussion on the commit list which will solve this through a 
different mechanism.  There's an active desire to avoid teaching GVN and 
related pieces (of which memcpyopt is one) about first class 
aggregates.  We don't have enough active users of the feature to justify 
and maintain the complexity.

If you haven't already seen it, this background may help: 
http://llvm.org/docs/Frontend/PerformanceTips.html#avoid-loads-and-stores-of-large-aggregate-type

The current proposal is to convert such aggregate loads and stores into 
their component pieces.  If that happens, you're example should come 
"for free" provided that the same example works when you break down
the
FCA into it's component pieces.  If it doesn't, please say so.

Philip

On 03/05/2015 04:21 PM, Reid Kleckner wrote:
> I think lib/Transforms/Scalar/MemCpyOptimizer.cpp might be the right 
> place for this, considering that most frontends will use memcpy for 
> that copy anyway. It already has some logic for byval args.
>
> On Thu, Mar 5, 2015 at 3:51 PM, Mircea Trofin <mtrofin at google.com 
> <mailto:mtrofin at google.com>> wrote:
>
>     Hello all,
>
>     I'm trying to find the pass that would convert from:
>
>     define void @main(%struct* byval %ptr) {
>       %val = load %struct* %ptr
>       %val.ptr = alloca %struct
>       store %struct %val, %struct* %val.ptr
>       call void @extern_func(%struct* byval %val.ptr)
>       ret void
>     }
>
>     to this:
>     define void @main(%struct* byval %ptr) {
>       call void @extern_func(%struct* byval %ptr)
>       ret void
>     }
>
>     First, am I missing something - would this be a correct optimization?
>
>     Thank you,
>     Mircea.
>
>     _______________________________________________
>     LLVM Developers mailing list
>     LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>     http://llvm.cs.uiuc.edu
>     http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150305/34f42542/attachment.html>