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

[vivek pandya via llvm-dev]

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 for
such 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>