[LLVMdev] Optimizing out redundant alloca involving byval params

[Mircea Trofin]

Sorry, that phase is part of the PNaCl toolchain. This would be LLVM 3.6,
would your comments still apply?

I tried -O3 to no avail. I suppose I'll get llvm 3.7, see if I can optimize
the latest snippet there (the one avoiding load/store), and see from there.

Thanks!

On Fri, Mar 6, 2015 at 12:01 PM Philip Reames <listmail at philipreames.com>
wrote:

>
> On 03/05/2015 06:16 PM, Mircea Trofin wrote:
>
>  Thanks!
>
>  Philip, do you mean I should transform the original IR to something like
> this?
>
>
> Yes.
>
> (...which is what -expand-struct-regs can do, when applied to my original
> input)
>
> Sorry, what?  This doesn't appear to be a pass in ToT.  Are you using an
> older version of LLVM?  If so, none of my comments will apply.
>
>
> define void @main(%struct* byval %ptr) {
>   %val.index = getelementptr %struct* %ptr, i32 0, i32 0
>   %val.field = load i32* %val.index
>   %val.index1 = getelementptr %struct* %ptr, i32 0, i32 1
>   %val.field2 = load i32* %val.index1
>   %val.ptr = alloca %struct
>   %val.ptr.index = getelementptr %struct* %val.ptr, i32 0, i32 0
>   store i32 %val.field, i32* %val.ptr.index
>   %val.ptr.index4 = getelementptr %struct* %val.ptr, i32 0, i32 1
>   store i32 %val.field2, i32* %val.ptr.index4
>   call void @extern_func(%struct* byval %val.ptr)
>   ret void
> }
>
>  If so, would you mind pointing me to the phase that would reduce this?
> (I'm assuming that's what you meant by "for free" - there's an existing
> phase I could use)
>
> I would expect GVN to get this.  If you can run this through a fully -O3
> pass order and get the right result, isolating the pass in question should
> be easy.
>
>
>  Thank you.
> Mircea.
>
>
> On Thu, Mar 5, 2015 at 4:39 PM Philip Reames <listmail at philipreames.com>
> wrote:
>
>>  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> 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
>>>
>>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing listLLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150308/786afbac/attachment.html>