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

[John Criswell via llvm-dev]

On 6/20/16 11:18 AM, vivek pandya wrote:
>
>
> On Mon, Jun 20, 2016 at 8:42 PM, John Criswell <jtcriswel at gmail.com 
> <mailto:jtcriswel at gmail.com>> 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.
>
>     If you see that happening, you can simply scan through a
>     function's def-use chains and see if any "indirect calls" are
>     really direct calls that cast the function pointer.  I believe
>     SAFECode has some code somewhere that does this if you need it.
>
> Dear Professor John,
>
> Thanks for pointing out this , but I wonder that how many such cases 
> may be there on average in a module? Is it too frequently seen?

As of 2-3 years ago, I saw this all the time.  It is easy enough to 
write an LLVM pass that iterates through all instructions and counts the 
number of call instructions that case their constant function pointer 
operand, so you can write that pass and see for yourself whether it is 
still an issue.

Regards,

John 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/20160620/f5820d38/attachment.html>