[PATCH] GlobalOpt: Apply fastcc to internal x86_thiscallcc functions

[Rafael Espíndola]

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.

Cheers,
Rafael