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

[John Criswell via llvm-dev]

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>