[llvm-dev] Suggestion / Help regarding new calling convention

[vivek pandya via llvm-dev]

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 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/a98816a0/attachment.html>