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

[Reid Kleckner via llvm-dev]

GlobalOpt already does this with fastcc, use it as a guide if you want to
do this:
https://github.com/llvm-mirror/llvm/blob/63b34cdf342b8265d98357008765b2563dd04e6c/lib/Transforms/IPO/GlobalOpt.cpp#L2023

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>