llvm dev - Jun 2016 - Suggestion / Help regarding new calling convention

> 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?
> 
> 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.
> 
> 
>>    DEBUG(dbgs() << "Function has LocalLinkage \n");
>> F->setCallingConv(CallingConv::GHC); 
>>  }
>> 
>> but we think threre should be clean and properway to do this perhaps
like:
>> 
>> if (F->hasLocalLinkage() && !F->hasAddressTaken()) {
>>     DEBUG(dbgs() << "Function has LocalLinkage \n");
>>     F->setCallingConv(CallingConv::NO_Callee_Saved);
>>   }
>> 
>> So I would like to know any better suggestions and if it is better to
add a new CC for this purpose then what aspects should be considered while
defining a new CC. Actually in this case the new CC does not really required to
define how parameters should be passed or any special rule for return value etc
, it just required to set callee saved registers to be none. So what are the
minimal things required to define such a CC?
>> 
>> Other alternative that I have thought was to add new attribute for
function and use it like following in
TargetFrameLowering::determineCalleeSaves()
>> 
>>  // In Naked functions we aren't going to save any registers.
>>   if (MF.getFunction()->hasFnAttribute(Attribute::Naked))
>>     return;
>> 
>> Any suggestions / thoughts are welcomed !
> 
> My humble opinion is that you should avoid hacks as they will likely break
as LLVM changes.
In-tree code with appropriate tests is unlikely to break. 
But we should avoid hacks anyway because they make LLVM harder to change in
general.


— 
Mehdi

> f the GHC calling convention or the naked function attribute guarantee that
you will always get the behavior that you want on all architectures, then go
ahead and use them; just make sure to add a clear and conspicuous comment
explaining why are you using them as it is not obvious.
> 
> If the GHC calling convention or the naked attribute does not guarantee to
give you what you need, I'd add an attribute or a calling convention.
> 
> That said, I'm not familiar enough with the code generator or these
attributes/calling conventions to tell you what you should do.  You'll need
input from others more familiar with them.
> 
> My two cents,
> 
> John Criswell
> 
>> 
>> Sincerely,
>> Vivek
>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> 
> -- 
> John Criswell
> Assistant Professor
> Department of Computer Science, University of Rochester
> http://www.cs.rochester.edu/u/criswell
<http://www.cs.rochester.edu/u/criswell>_______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160621/b2f1ad41/attachment.html>

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).

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/20160621/1747a488/attachment.html>

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>