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

[vivek pandya via llvm-dev]

On Mon, Jun 20, 2016 at 8:42 PM, John Criswell <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?

>
>    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.  If 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.
>
Actually I am not really in favor of using this kind of hack because using
GHC CC or naked attribute have there other rules (in addition to no callee
saved registers) and that are not really wanted. So it is desired to add
new CC or attribute to achieve the required effect.

Sincerely,
Vivek

>
> 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 listllvm-dev at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> --
> 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/20160620/e775e782/attachment.html>