Indeed. However, I wouldn't have called variable number of arguments a "sophisticated feature". :-) /Patrik Hägglund -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Krzysztof Parzyszek Sent: den 2 oktober 2013 19:12 To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] builtin_apply? I think varargs functions would be an example of where this builtin would not work. -K On 10/2/2013 2:32 AM, Patrik Hägglund H wrote:> Interesting. Just having __builtin_apply_args() (and a correspoding > __builtin_apply_args_size()), would make it possible to do a memcpy > store of arguments to a (varargs) function, which sometimes is useful > for our users (for debug/trace purposes). > > /Patrik Hägglund > > *From:*llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > *On Behalf Of *Eric Christopher > *Sent:* den 2 oktober 2013 07:22 > *To:* reed kotler > *Cc:* LLVMdev at cs.uiuc.edu > *Subject:* Re: [LLVMdev] builtin_apply? > > __builtin_apply is an abomination. Even in GCC it is held to have been a > bad idea. > > --eric > > On Oct 1, 2013 10:03 PM, "reed kotler" <rkotler at mips.com > <mailto:rkotler at mips.com>> wrote: > > why does clang not support builtin_apply? > > > 6.5 Constructing Function Calls > > Using the built-in functions described below, you can record the > arguments a function received, and call another function with the same > arguments, without knowing the number or types of the arguments. > > You can also record the return value of that function call, and later > return that value, without knowing what data type the function tried to > return (as long as your caller expects that data type). > > However, these built-in functions may interact badly with some > sophisticated features or other extensions of the language. It is, > therefore, not recommended to use them outside very simple functions > acting as mere forwarders for their arguments. > > - Built-in Function: void * *__builtin_apply_args* () > > This built-in function returns a pointer to data describing how to > perform a call with the same arguments as are passed to the current > function. > > The function saves the arg pointer register, structure value address, > and all registers that might be used to pass arguments to a function > into a block of memory allocated on the stack. Then it returns the > address of that block. > > - Built-in Function: void * *__builtin_apply* (void (*function)(), void > *arguments, size_t size) > > This built-in function invokes function with a copy of the parameters > described by arguments and size. > > The value of arguments should be the value returned by > |__builtin_apply_args|. The argument size specifies the size of the > stack argument data, in bytes. > > This function returns a pointer to data describing how to return > whatever value is returned by function. The data is saved in a block of > memory allocated on the stack. > > It is not always simple to compute the proper value for size. The value > is used by |__builtin_apply| to compute the amount of data that should > be pushed on the stack and copied from the incoming argument area. > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
I would also like so tee support for __builtin_apply*. We use it in macros and such. If others are interested, please speak up. -Jan On 02/10/2013 20:51, Patrik Hägglund H wrote:> Indeed. However, I wouldn't have called variable number of arguments a "sophisticated feature". :-) > > /Patrik Hägglund > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Krzysztof Parzyszek > Sent: den 2 oktober 2013 19:12 > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] builtin_apply? > > I think varargs functions would be an example of where this builtin > would not work. > > -K > > > On 10/2/2013 2:32 AM, Patrik Hägglund H wrote: >> Interesting. Just having __builtin_apply_args() (and a correspoding >> __builtin_apply_args_size()), would make it possible to do a memcpy >> store of arguments to a (varargs) function, which sometimes is useful >> for our users (for debug/trace purposes). >> >> /Patrik Hägglund >> >> *From:*llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> *On Behalf Of *Eric Christopher >> *Sent:* den 2 oktober 2013 07:22 >> *To:* reed kotler >> *Cc:* LLVMdev at cs.uiuc.edu >> *Subject:* Re: [LLVMdev] builtin_apply? >> >> __builtin_apply is an abomination. Even in GCC it is held to have been a >> bad idea. >> >> --eric >> >> On Oct 1, 2013 10:03 PM, "reed kotler" <rkotler at mips.com >> <mailto:rkotler at mips.com>> wrote: >> >> why does clang not support builtin_apply? >> >> >> 6.5 Constructing Function Calls >> >> Using the built-in functions described below, you can record the >> arguments a function received, and call another function with the same >> arguments, without knowing the number or types of the arguments. >> >> You can also record the return value of that function call, and later >> return that value, without knowing what data type the function tried to >> return (as long as your caller expects that data type). >> >> However, these built-in functions may interact badly with some >> sophisticated features or other extensions of the language. It is, >> therefore, not recommended to use them outside very simple functions >> acting as mere forwarders for their arguments. >> >> - Built-in Function: void * *__builtin_apply_args* () >> >> This built-in function returns a pointer to data describing how to >> perform a call with the same arguments as are passed to the current >> function. >> >> The function saves the arg pointer register, structure value address, >> and all registers that might be used to pass arguments to a function >> into a block of memory allocated on the stack. Then it returns the >> address of that block. >> >> - Built-in Function: void * *__builtin_apply* (void (*function)(), void >> *arguments, size_t size) >> >> This built-in function invokes function with a copy of the parameters >> described by arguments and size. >> >> The value of arguments should be the value returned by >> |__builtin_apply_args|. The argument size specifies the size of the >> stack argument data, in bytes. >> >> This function returns a pointer to data describing how to return >> whatever value is returned by function. The data is saved in a block of >> memory allocated on the stack. >> >> It is not always simple to compute the proper value for size. The value >> is used by |__builtin_apply| to compute the amount of data that should >> be pushed on the stack and copied from the incoming argument area. >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >
The __builtin_va_arg_pack() and __builtin_va_arg_pack_len() builtins are useful in this context and, unlike __builtin_apply(), are possible to implement correctly in the general case. I believe that some GNU system headers use them when they are available, so they are probably worth supporting. I'd love to see __builtin_apply() implemented and working properly too, but on most architectures / ABIs it's possible to implement it in such a way that it works except for some corner cases and on others it's impossible to implement correctly at all. Code that uses it is either non-portable or just plain broken currently, and that's not something I'd like to see clang encourage. David On 16 Oct 2013, at 10:19, Jan Smets <jan.smets at alcatel-lucent.com> wrote:> I would also like so tee support for __builtin_apply*. We use it in macros and such. > If others are interested, please speak up. > -Jan > > On 02/10/2013 20:51, Patrik Hägglund H wrote: >> Indeed. However, I wouldn't have called variable number of arguments a "sophisticated feature". :-) >> >> /Patrik Hägglund >> >> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Krzysztof Parzyszek >> Sent: den 2 oktober 2013 19:12 >> To: llvmdev at cs.uiuc.edu >> Subject: Re: [LLVMdev] builtin_apply? >> >> I think varargs functions would be an example of where this builtin >> would not work. >> >> -K >> >> >> On 10/2/2013 2:32 AM, Patrik Hägglund H wrote: >>> Interesting. Just having __builtin_apply_args() (and a correspoding >>> __builtin_apply_args_size()), would make it possible to do a memcpy >>> store of arguments to a (varargs) function, which sometimes is useful >>> for our users (for debug/trace purposes). >>> >>> /Patrik Hägglund >>> >>> *From:*llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >>> *On Behalf Of *Eric Christopher >>> *Sent:* den 2 oktober 2013 07:22 >>> *To:* reed kotler >>> *Cc:* LLVMdev at cs.uiuc.edu >>> *Subject:* Re: [LLVMdev] builtin_apply? >>> >>> __builtin_apply is an abomination. Even in GCC it is held to have been a >>> bad idea. >>> >>> --eric >>> >>> On Oct 1, 2013 10:03 PM, "reed kotler" <rkotler at mips.com >>> <mailto:rkotler at mips.com>> wrote: >>> >>> why does clang not support builtin_apply? >>> >>> >>> 6.5 Constructing Function Calls >>> >>> Using the built-in functions described below, you can record the >>> arguments a function received, and call another function with the same >>> arguments, without knowing the number or types of the arguments. >>> >>> You can also record the return value of that function call, and later >>> return that value, without knowing what data type the function tried to >>> return (as long as your caller expects that data type). >>> >>> However, these built-in functions may interact badly with some >>> sophisticated features or other extensions of the language. It is, >>> therefore, not recommended to use them outside very simple functions >>> acting as mere forwarders for their arguments. >>> >>> - Built-in Function: void * *__builtin_apply_args* () >>> >>> This built-in function returns a pointer to data describing how to >>> perform a call with the same arguments as are passed to the current >>> function. >>> >>> The function saves the arg pointer register, structure value address, >>> and all registers that might be used to pass arguments to a function >>> into a block of memory allocated on the stack. Then it returns the >>> address of that block. >>> >>> - Built-in Function: void * *__builtin_apply* (void (*function)(), void >>> *arguments, size_t size) >>> >>> This built-in function invokes function with a copy of the parameters >>> described by arguments and size. >>> >>> The value of arguments should be the value returned by >>> |__builtin_apply_args|. The argument size specifies the size of the >>> stack argument data, in bytes. >>> >>> This function returns a pointer to data describing how to return >>> whatever value is returned by function. The data is saved in a block of >>> memory allocated on the stack. >>> >>> It is not always simple to compute the proper value for size. The value >>> is used by |__builtin_apply| to compute the amount of data that should >>> be pushed on the stack and copied from the incoming argument area. >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev