vivek pandya via llvm-dev
2016-Jun-21 16:27 UTC
[llvm-dev] Suggestion / Help regarding new calling convention
On Tue, Jun 21, 2016 at 8:58 PM, John Criswell <jtcriswel at gmail.com> wrote:> On 6/20/16 11:29 PM, Mehdi Amini wrote: > > > On Jun 20, 2016, at 11:12 AM, John Criswell via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > On 6/20/16 9:39 AM, vivek pandya via llvm-dev wrote: > > Dear Community, > > To improve current interprocedural register allocation (IPRA) , we have > planned to set callee saved registers to none for local functions, > currently I am doing it in following way: > > if (F->hasLocalLinkage() && !F->hasAddressTaken()) { > > > As an aside, you might want to analyze how many functions have both local > linkage and are not address taken. I recall that many functions returned > false for hasAddressTaken() because some direct calls casted the function > to a different function type before calling it. Such functions are still > not address taken, but the simple hasAddressTaken() method can't determine > it. > > > Looks like hasAddressTaken could be updated to handle these simple case > maybe? > > > That might make sense if it has not been fixed already. Another approach > (if in-tree LLVM passes are frequently checking for indirect calls) would > be to write a simple analysis pass that lazily computes the information on > demand. That way, if multiple passes are checking the same function > repeatedly, it gets cached in the analysis pass instead of being recomputed > (so long as the analysis pass is not invalidated by a transform). > > Addition of new pass will require other passes to be modified. So it willbe good have strong reason for adding new pass. Other wise I am in favor to modify hasAddressTaken(). -Vivek> Regards, > > John Criswell > > > -- > John Criswell > Assistant Professor > Department of Computer Science, University of Rochesterhttp://www.cs.rochester.edu/u/criswell > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160621/a98816a0/attachment.html>
vivek pandya via llvm-dev
2016-Jun-21 18:06 UTC
[llvm-dev] Suggestion / Help regarding new calling convention
On Tue, Jun 21, 2016 at 9:57 PM, vivek pandya <vivekvpandya at gmail.com> wrote:> > > On Tue, Jun 21, 2016 at 8:58 PM, John Criswell <jtcriswel at gmail.com> > wrote: > >> On 6/20/16 11:29 PM, Mehdi Amini wrote: >> >> >> On Jun 20, 2016, at 11:12 AM, John Criswell via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >> On 6/20/16 9:39 AM, vivek pandya via llvm-dev wrote: >> >> Dear Community, >> >> To improve current interprocedural register allocation (IPRA) , we have >> planned to set callee saved registers to none for local functions, >> currently I am doing it in following way: >> >> if (F->hasLocalLinkage() && !F->hasAddressTaken()) { >> >> >> As an aside, you might want to analyze how many functions have both local >> linkage and are not address taken. I recall that many functions returned >> false for >> >> I think here you mean "returned true" but it should not return true forsuch case. Or I am making any mistake in understanding this? - Vivek> hasAddressTaken() because some direct calls casted the function to a >> different function type before calling it. Such functions are still not >> address taken, but the simple hasAddressTaken() method can't determine it. >> >> >> Looks like hasAddressTaken could be updated to handle these simple case >> maybe? >> >> >> That might make sense if it has not been fixed already. Another approach >> (if in-tree LLVM passes are frequently checking for indirect calls) would >> be to write a simple analysis pass that lazily computes the information on >> demand. That way, if multiple passes are checking the same function >> repeatedly, it gets cached in the analysis pass instead of being recomputed >> (so long as the analysis pass is not invalidated by a transform). >> >> Addition of new pass will require other passes to be modified. So it will > be good have strong reason for adding new pass. Other wise I am in favor to > modify hasAddressTaken(). > > -Vivek > > >> Regards, >> >> John Criswell >> >> >> -- >> John Criswell >> Assistant Professor >> Department of Computer Science, University of Rochesterhttp://www.cs.rochester.edu/u/criswell >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160621/476ff774/attachment.html>
John Criswell via llvm-dev
2016-Jun-21 20:56 UTC
[llvm-dev] Suggestion / Help regarding new calling convention
On 6/21/16 11:27 AM, vivek pandya wrote:> > > On Tue, Jun 21, 2016 at 8:58 PM, John Criswell <jtcriswel at gmail.com > <mailto:jtcriswel at gmail.com>> wrote: > > On 6/20/16 11:29 PM, Mehdi Amini wrote: >> >>> On Jun 20, 2016, at 11:12 AM, John Criswell via llvm-dev >>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>> >>> On 6/20/16 9:39 AM, vivek pandya via llvm-dev wrote: >>>> Dear Community, >>>> >>>> To improve current interprocedural register allocation (IPRA) , >>>> we have planned to set callee saved registers to none for local >>>> functions, currently I am doing it in following way: >>>> >>>> if (F->hasLocalLinkage() && !F->hasAddressTaken()) { >>> >>> As an aside, you might want to analyze how many functions have >>> both local linkage and are not address taken. I recall that >>> many functions returned false for hasAddressTaken() because some >>> direct calls casted the function to a different function type >>> before calling it. Such functions are still not address taken, >>> but the simple hasAddressTaken() method can't determine it. >> >> Looks like hasAddressTaken could be updated to handle these >> simple case maybe? > > That might make sense if it has not been fixed already. Another > approach (if in-tree LLVM passes are frequently checking for > indirect calls) would be to write a simple analysis pass that > lazily computes the information on demand. That way, if multiple > passes are checking the same function repeatedly, it gets cached > in the analysis pass instead of being recomputed (so long as the > analysis pass is not invalidated by a transform). > > Addition of new pass will require other passes to be modified. So it > will be good have strong reason for adding new pass. Other wise I am > in favor to modify hasAddressTaken().Addition of a new pass means that existing passes would not get the benefit of the new pass until they are updated to use it. You would not need to update existing passes though it would probably make sense to do so if using a separate analysis pass is better. Also keep in mind that the two approaches are not mutually exclusive. Updating hasAddressTaken() to take casting into account would probably not increase its run-time much. The point of using a pass is to cache the results of hasAddressTaken(); the pass makes sense if the hasAddressTaken() queries are being performed repeatedly on the same functions by multiple passes. Regards, John Criswell> > -Vivek > > Regards, > > John Criswell > > > -- > John Criswell > Assistant Professor > Department of Computer Science, University of Rochester > http://www.cs.rochester.edu/u/criswell > >-- John Criswell Assistant Professor Department of Computer Science, University of Rochester http://www.cs.rochester.edu/u/criswell -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160621/90e039b3/attachment.html>
John Criswell via llvm-dev
2016-Jun-21 21:00 UTC
[llvm-dev] Suggestion / Help regarding new calling convention
On 6/21/16 1:06 PM, vivek pandya wrote:> > > On Tue, Jun 21, 2016 at 9:57 PM, vivek pandya <vivekvpandya at gmail.com > <mailto:vivekvpandya at gmail.com>> wrote: > > > > On Tue, Jun 21, 2016 at 8:58 PM, John Criswell > <jtcriswel at gmail.com <mailto:jtcriswel at gmail.com>> wrote: > > On 6/20/16 11:29 PM, Mehdi Amini wrote: >> >>> On Jun 20, 2016, at 11:12 AM, John Criswell via llvm-dev >>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> >>> wrote: >>> >>> On 6/20/16 9:39 AM, vivek pandya via llvm-dev wrote: >>>> Dear Community, >>>> >>>> To improve current interprocedural register allocation >>>> (IPRA) , we have planned to set callee saved registers to >>>> none for local functions, currently I am doing it in >>>> following way: >>>> >>>> if (F->hasLocalLinkage() && !F->hasAddressTaken()) { >>> >>> As an aside, you might want to analyze how many functions >>> have both local linkage and are not address taken. I recall >>> that many functions returned false for > > I think here you mean "returned true" but it should not return true > for such case. Or I am making any mistake in understanding this?You're correct; I said it backwards: hasAddressTaken() returns true when it could return false because the function pointer is casted to another function pointer type in one or more direct calls. To be clear, my experience is a bit dated; I'm recalling details from LLVM 3.2. You should therefore test it for yourself to see if the issue still exists and if it is pessimizing your results. I mentioned it because the problem existed for a long time during SAFECode's development, and so I got into the habit of never using hasAddressTaken(). Regards, John Criswell> > - Vivek > >>> hasAddressTaken() because some direct calls casted the >>> function to a different function type before calling it. >>> Such functions are still not address taken, but the simple >>> hasAddressTaken() method can't determine it. >> >> Looks like hasAddressTaken could be updated to handle these >> simple case maybe? > > That might make sense if it has not been fixed already. > Another approach (if in-tree LLVM passes are frequently > checking for indirect calls) would be to write a simple > analysis pass that lazily computes the information on demand. > That way, if multiple passes are checking the same function > repeatedly, it gets cached in the analysis pass instead of > being recomputed (so long as the analysis pass is not > invalidated by a transform). > > Addition of new pass will require other passes to be modified. So > it will be good have strong reason for adding new pass. Other wise > I am in favor to modify hasAddressTaken(). > > -Vivek > > Regards, > > John Criswell > > > -- > John Criswell > Assistant Professor > Department of Computer Science, University of Rochester > http://www.cs.rochester.edu/u/criswell > > >-- John Criswell Assistant Professor Department of Computer Science, University of Rochester http://www.cs.rochester.edu/u/criswell -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160621/98756ee5/attachment.html>