[PATCH] GlobalOpt: Apply fastcc to internal x86_thiscallcc functions

[Nick Lewycky]

On 5 February 2014 10:21, Rafael Espíndola <rafael.espindola at gmail.com>wrote:

> > 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.
>
> We should at least make that explicit in the language reference. In
> the long run llvm.used and llvm.compiler_used should just be part of
> the linkage, making them easier to use. We could then, for example,
> require in the verifier that the WebKit JS CC is only used in
> functions with a linkage that imply an invisible external use.
>

I conceptually agree, but I think that's an issue beyond this optimization.
I think this patch LGTM, Rafael?


> > If you just want to flip the naming around here to something like
> > isProfitableToMakeFastCC() then that works for me.
>

isProfitableToMakeFastCC sounds nice. What really matters is that it needs
to be a whitelist.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140224/390a02fc/attachment.html>