[cfe-commits] [PATCH] Add pnaclcall convention to Native Client targets

[Eli Friedman]

On Tue, Oct 16, 2012 at 8:52 AM, Derek Schuff <dschuff at google.com> wrote:
> Ping!
> There are several bits that had to be touched, but the change is very
> straightforward.
>
> On Thu, Oct 11, 2012 at 2:53 PM, Derek Schuff <dschuff at google.com> wrote:
>> Background:
>> Because PNaCl bitcode must be target-independent, it uses some
>> different bitcode representations from other targets (e.g. byval and
>> sret for structures). This means that without additional type
>> information, it cannot meet some native ABI requirements for some
>> targets (e.g. passing structures containing unions by value on
>> x86-64). To allow generation of code which uses the correct native
>> ABIs, we also support triples such as x86_64-nacl, which uses
>> target-dependent IR (as opposed to le32-nacl, which uses byval and
>> sret).
>>
>> To allow interoperation between the two types of code, this patch adds
>> a calling convention attribute to be used in code compiled with the
>> target-dependent triple, which will generate code using the le32-style
>> bitcode. This calling convention does not need to be explicitly
>> supported in the backend because it determines bitcode representation
>> rather than native conventions (the backend just needs to undersand
>> how to handle byval and sret for the Native Client OS).
>>
>> This patch implements __attribute__((pnaclcall)) to generate calls in
>> bitcode according to the le32 bitcode conventions, an attribute which
>> is accepted by any Native Client target, but issues a warning
>> otherwise.
>>
>> Please take a look, thanks.
>> -Derek

+  // There appears to be no way to get the callingconv here, so just use
+  // the native version. FIXME: throw an early error if a function has
+  // pnaclcall attribute and varargs.

CGF.CurFnInfo->getASTCallingConvention() ?


I don't see any other issues.

-Eli