[PATCH] GlobalOpt: Apply fastcc to internal x86_thiscallcc functions

Reid Kleckner rnk at google.com
Wed Feb 5 10:15:54 PST 2014


On Wed, Feb 5, 2014 at 10:05 AM, Rafael EspĂ­ndola <
rafael.espindola at gmail.com> wrote:

> On 5 February 2014 12:13, Reid Kleckner <rnk at google.com> wrote:
> > Hi nlewycky,
> >
> > There's no real reason we shouldn't be doing this, so far as I know.
> >
> > http://llvm-reviews.chandlerc.com/D2705
> >
> > Files:
> >   lib/Transforms/IPO/GlobalOpt.cpp
> >   test/Transforms/GlobalOpt/fastcc.ll
> >
> > Index: lib/Transforms/IPO/GlobalOpt.cpp
> > ===================================================================
> > --- lib/Transforms/IPO/GlobalOpt.cpp
> > +++ lib/Transforms/IPO/GlobalOpt.cpp
> > @@ -1898,6 +1898,15 @@
> >    }
> >  }
> >
> > +/// Return true if this is a calling convention that we'd like to
> change.  The
> > +/// idea here is that we don't want to mess with the convention if the
> user
> > +/// explicitly requested something interesting like coldcc, GHC, or
> anyregcc.
> > +static bool shouldTransformCC(Function *F) {
> > +  CallingConv::ID CC = F->getCallingConv();
> > +  // FIXME: Is it worth transforming x86_stdcallcc and x86_fastcallcc?
> > +  return CC == CallingConv::C || CC == CallingConv::X86_ThisCall;
> > +}
>
> It seems strange to base the legality on the CC. The language
> reference has no extra guarantees for one CC over the other (like it
> will not be turned into fastcc). Maybe we should explicitly say that
> it is legal to change the CC of any internal/private function that is
> not llvm.used or llvm.compiler_used?
>
> Profitability based on CC makes sense. Like not converting coldcc for
> example.
>

What about things like the WebKit JS CC?  I assume the reason they do it
that way is so that they can get GC roots in memory on the stack, and
changing something like this to fastcc would break their GC.  The same
might apply to the GHC convention, although I doubt it.  Changing the CC
feels a lot like eliminating frame pointers, in that could mess with
unwinders.

I agree that LLVM IR semantics *allow* us to do this, but I didn't feel the
need to rock this particular boat.

If you just want to flip the naming around here to something like
isProfitableToMakeFastCC() then that works for me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140205/73f20e53/attachment.html>


More information about the llvm-commits mailing list