This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [cfe-dev] C++11: new builtin to allow constexpr to be applied to performance-critical functions


On Sat, Oct 20, 2012 at 12:53 AM, Chandler Carruth <chandlerc@google.com> wrote:
> On Fri, Oct 19, 2012 at 10:04 PM, Richard Smith <richard@metafoo.co.uk> wrote:
>>
>> [Crossposted to both GCC and Clang dev lists]
>>
>> Hi,
>>
>> One issue facing library authors wanting to use C++11's constexpr feature is that the same implementation must be provided for both the case of function invocation substitution and for execution at runtime. Due to the constraints on constexpr function definitions, this can force an implementation of a library function to be inefficient. To counteract this, I'd like to propose the addition of a builtin:
>>
>>   bool __builtin_constexpr_p()
>>
>> This builtin would only be supported within constexpr function definitions. If the containing function is undergoing function invocation substitution, it returns true. Otherwise, it returns false. Hence we can implement library functions with a pattern like:
>>
>>   constexpr int constexpr_strncmp(const char *p, const char *q, size_t n) {
>>     return !n ? 0 : *p != *q ? *p - *q : !*p ? 0 : constexpr_strncmp(p+1, q+1, n-1);
>>   }
>>   __attribute__((always_inline)) constexpr int my_strncmp(const char *p, const char *q, size_t n) {
>>     return __builtin_constexpr_p() ? constexpr_strncmp(p, q, n) : strncmp(p, q, n);
>>   }
>>
>> Does this seem reasonable?
>
>
> Yes, especially the primary functionality. However, I have some
> concerns about the interface. Let me hypothesize a different
> interface:
>
> This stays the same...
>> constexpr int constexpr_strncmp(const char *p, const char *q, size_t n) {
>>   return !n ? 0 : *p != *q ? *p - *q : !*p ? 0 : constexpr_strncmp(p+1, q+1, n-1);
>> }
>
>
> But here we do something different on the actual declaration:
>>
>> [[constexpr_alias(constexpr_strncmp)]]
>> int strncmp(const char *p, const char *q, size_t n);
>
>
> When parsing the *declaration* of this function, we lookup the
> function name passed to constexpr_alias. We must find a constexpr
> function with an identical signature. Then, at function invocation
> substitution of strncmp, we instead substitute the body of
> constexpr_strncmp.
>
> This seems more direct (no redirection in the code), and it also
> provides a specific advantage of allowing this to be easily added to
> an existing declaration in a declaration-only header file without
> impacting or changing the name of the runtime executed body or
> definition.
>
> -Chandler
>
> PS: Sorry for the dup Clang folks, the GCC list doesn't like my mail client.

The way to solve this issue is:

  1) to make most of the restrictions on constexpr functions evaporate.

   2) resist the temptation of introducing a primitive to query the state of
       the optimizers.

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]