Philip Reames
2015-Mar-06 20:01 UTC
[LLVMdev] Optimizing out redundant alloca involving byval params
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 <mailto: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 >> <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 <mailto: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/20150306/7f1a2a6d/attachment.html>
Mircea Trofin
2015-Mar-08 16:44 UTC
[LLVMdev] Optimizing out redundant alloca involving byval params
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>
Mircea Trofin
2015-Mar-08 17:02 UTC
[LLVMdev] Optimizing out redundant alloca involving byval params
errata: I am on 3.6 full stop. I *thought* there was a 3.7 available, based on the title of http://llvm.org/docs/ ("LLVM 3.7 documentation"). I suppose the docs are ahead of the release schedule? On Sun, Mar 8, 2015 at 9:44 AM Mircea Trofin <mtrofin at google.com> wrote:> 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/6d2f7db7/attachment.html>
Possibly Parallel Threads
- [LLVMdev] Optimizing out redundant alloca involving byval params
- [LLVMdev] Optimizing out redundant alloca involving byval params
- [LLVMdev] Optimizing out redundant alloca involving byval params
- [RFC] FileCheck: (dis)allowing unused prefixes
- [RFC] FileCheck: (dis)allowing unused prefixes