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

Reid Kleckner via llvm-dev llvm-dev at lists.llvm.org
Mon Jun 20 08:25:12 PDT 2016

GlobalOpt already does this with fastcc, use it as a guide if you want to
do this:

You can't just change the convention of F, you need to update the
convention used at F's call sites.

Unfortunately, while LLVM has PreserveMost and PreservesAll calling
conventions, it does not appear to have an equivalent PreservesNone/Least.

On Mon, Jun 20, 2016 at 7:39 AM, vivek pandya via llvm-dev <
llvm-dev at lists.llvm.org> 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()) {
>    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 !
> Sincerely,
> Vivek
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> 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/20160620/959c761f/attachment.html>

More information about the llvm-dev mailing list