220 30869 <34826fd2-84db-4ce9-b30b-66a95601918a@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Gonzalo BG Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Detecting compile-time evaluation Date: Sat, 11 Feb 2017 10:43:53 -0800 (PST) Lines: 206 Approved: news@gmane.org Message-ID: <34826fd2-84db-4ce9-b30b-66a95601918a@isocpp.org> References: <86a47916-27c3-4e29-862f-9b4e1f105c1c@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1004_293586593.1486838634069" X-Trace: blaine.gmane.org 1486838636 15164 195.159.176.226 (11 Feb 2017 18:43:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 11 Feb 2017 18:43:56 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDTOBQEKX4PRB2VW7XCAKGQEGCDVQ7Y@isocpp.org Sat Feb 11 19:43:51 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f198.google.com ([209.85.192.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ccceE-0003b1-1E for gclcip-std-proposals@m.gmane.org; Sat, 11 Feb 2017 19:43:50 +0100 Original-Received: by mail-pf0-f198.google.com with SMTP id 145sf62939420pfv.6 for ; Sat, 11 Feb 2017 10:43:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=zWDzBNodUJwfX0uVeo8Ie97rLTDUDRXxhC1n0VFAyvc=; b=c+XqBBnv36xq5J1lFbtC7DD207tD5UiSiVkLO6E8q2AX7B89j5xtI/dUM4rS3DqK0Y HBjvBZQ0TH/xvYVLPTB84R+mXtkTnd1z0/kKzkbuLzeVwXXiCpGJgH0yCCnIBwtIhX9P QZ5erhJZNYH+5jv8RnKacX3Qp+L94GyiFTMbzZ5cphn4UELAIa1LzmDFrZ/4JiqjlGOb CQUqIK2dVlxF5qzCAnO1Lh8IMb7Pf7W+pvOk+WifBb/jT3yQLm+URi1wMByF6MhPaB+m gYayo8JvYOOrTjwMi9UGkVveWKbWZjAfKcdCN417y/JlWFE0u46f0uXo4R4A8nbML8ZB bJXw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=zWDzBNodUJwfX0uVeo8Ie97rLTDUDRXxhC1n0VFAyvc=; b=Xmh23y1F8gSMrKf4D6WjAW2UQ7c0ba70T7av9yJqDM5QrysXA0I159e4IoksHMT11U gouMKiPS+RSNC9djpDsunoYFxL1MuUPZtx9O77PXVfLZnL++rtaOx96UbuIIPTkJyHt0 fMKx0bh+ZtszYUMNQiwUtRJgTgE0T61CxB1CXVO0Zdm9aSfhx7xNvWHGnunnYO1LTge4 jA+3EgyuaG4wxAdzbwf37BfAm5aCdtKTCGWWciTZqTFSuvdihN4Of6CdOaEf2YZZVQzy g0lKchxg9lijAp3hNM4b1D88hatjuuxlQ8mfFbo6uK11swsdXOPokb3wqWDgthi3lSiu ntow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=zWDzBNodUJwfX0uVeo8Ie97rLTDUDRXxhC1n0VFAyvc=; b=ChzK24zX7hMAjYKuDoUy+njV0nfshaRru0cOxCP2uX3pVGqRwCXncTwrRDCp7rx+bs JI8ojiE/v5Xlfy/VGRRW6Tz+e7pVyR7vj5hhilVa6yO4s78LiH56pq0NNoz4VnLNZ7RX 8gf9gWRA7Q/15BH2X1H0DDmYkifUBnkr0Gs2KzBKncRmriLsYU1Ory26vscZ01CGbd7u wtbwb9yaOc1R2TAiVXoAG4T1GsZ/kurPtyfP7VVa8vFJZCofCzGobCUcPjiPQgjzI1jN qAMFNmbbXZuYZxEEyqNjnk0g+rSSu8nfQdazrNbcbIKaBJap8GLHS8+DJUBQd95GJRnd 1qsw== X-Gm-Message-State: AMke39mmuT3wSYB8OVlceRXwjLXrXH6/p4bwllG9ECaw7OveSpPTHJ6LEnkBWtVf7kB1ig== X-Received: by 10.99.147.25 with SMTP id b25mr5779288pge.93.1486838635415; Sat, 11 Feb 2017 10:43:55 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.20.230 with SMTP id r35ls25590138otr.25.gmail; Sat, 11 Feb 2017 10:43:54 -0800 (PST) X-Received: by 10.157.20.145 with SMTP id d17mr1206470ote.18.1486838634629; Sat, 11 Feb 2017 10:43:54 -0800 (PST) In-Reply-To: <86a47916-27c3-4e29-862f-9b4e1f105c1c@isocpp.org> X-Original-Sender: gonzalobg88@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:30869 Archived-At: ------=_Part_1004_293586593.1486838634069 Content-Type: multipart/alternative; boundary="----=_Part_1005_2054971813.1486838634069" ------=_Part_1005_2054971813.1486838634069 Content-Type: text/plain; charset=UTF-8 @Thiago: > We used to have this problem with Clang: for example, qCountTrailingZeroBits wasn't constexpr with Clang until 3.8, because we couldn't use __builtin_ctz in a constexpr context. Given that you have run into the issue, I cannot find the logic in the following statement: > But in our experience, any algorithm that can be complex enough to warrant SIMD optimisation is too complex for a constexpr inline function. You seem to be arguing that using __builtin_ctz in a constexpr function is reasonable, but using any other intrinsics while solving problems in any other domain is not. Care to elaborate on which experience makes you say so? I am not a Qt user, but at least outside from Qt it is easy to find examples of algorithms that are useful in constexpr functions, but for which one always wants to use intrinsics/SIMD at run-time: 1) The post C++11 standard library. Before C++11 I rarely saw people reimplementing pow, log, exp, sin, ... After C++11 almost every single project had its own pow constexpr implementation because neither the math functions from the standard library nor the builtins provided by the compilers worked inside constant expressions for years after C++11. The run-time performance of these functions was, and still is, horrible. The fix for this was to make the math functions in the standard constexpr, but this did not solve the underlying issue (which is being discussed here). 2) Math/Linear algebra libraries like Eigen3, Blaze, ... which have used expression template hacks for compile-time computations for the last 20 years _cannot_ use constexpr anywhere in their API (and don't really use it almost anywhere) because somewhere down the pipeline they do use intrinsics (and pragmas and what not) for run-time performance reasons. Do you consider using a log function (which is implemented using intrinsics in most standard libraries) or multiplying two 4x4 matrices "too complex" for constexpr functions? @Nicol Bolas: > I'm not sure what would keep `if constexpr()` from working under those circumstances. You would simply define it to work if the compiler chooses to execute the function at compile time I am quoting Eric from this issue which mentions ODR violations as a potential issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79452 >There are definitely opportunities for ODR violations here, or at least >something like them. Consider the following case: > >template >constexpr bool foo(T) { > if constexpr(__ctfe__) > return true; > else > return false >} > >static_assert(foo(0)); >auto runtime = foo(0); > >Both calls instantiate foo with the same template arguments, so they should >seemingly both get the same instantiation with the w/e value of `__ctfe__` was >when the implicit instantiations occurred. Therefore one of the two calls to >foo() will return the wrong answer. > >This problem is made ever worse if `__builtin_constant_expression` allows you >to generate non-dependent compile-time expressions based on the function >arguments. > >One solution would be to consider the instantiation of `foo` to be value >dependent on a "implicit template parameter" representing `__ctfe__`. -- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/34826fd2-84db-4ce9-b30b-66a95601918a%40isocpp.org. ------=_Part_1005_2054971813.1486838634069 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
@Thiago:

> We used to hav= e this problem with Clang: for example, qCountTrailingZeroBits =C2=A0wasn&#= 39;t constexpr with Clang until 3.8, because we couldn't use __builtin_= ctz=C2=A0=C2=A0in a constexpr context.=C2=A0

Given= that you have run into the issue, I cannot find the logic in the following= statement:

> But in our experience, any algorit= hm that can be complex enough to warrant=C2=A0SIMD optimisation is too comp= lex for a constexpr inline function.

You seem to be argu= ing that using __builtin_ctz in a constexpr function is reasonable, but usi= ng any other intrinsics while solving problems in any other domain is not. = Care to elaborate on which experience makes you say so?

I= am not a Qt user, but at least outside from Qt it is easy to find examples= of algorithms that are useful in constexpr functions, but for which one al= ways wants to use intrinsics/SIMD at run-time:

1) = The post C++11 standard library. Before C++11 I rarely saw people reimpleme= nting pow, log, exp, sin, ... After C++11 almost every single project had i= ts own pow constexpr implementation because neither the math functions from= the standard library nor the builtins provided by the compilers worked ins= ide constant expressions for years after C++11. The run-time performance of= these functions was, and still is, horrible. The fix for this was to make = the math functions in the standard constexpr, but this did not solve the un= derlying issue (which is being discussed here).

2) Math/Linear algeb= ra libraries like Eigen3, Blaze, ... which have used expression template ha= cks for compile-time computations for the last 20 years _cannot_ use conste= xpr anywhere in their API (and don't really use it almost anywhere) bec= ause somewhere down the pipeline they do use intrinsics (and pragmas and wh= at not) for run-time performance reasons.

Do y= ou consider using a log function (which is implemented using intrinsics in = most standard libraries) or multiplying two 4x4 matrices "too complex&= quot; for constexpr functions?

@Nicol Bolas:
=

> I'm not sure what would keep `if constexpr()` = from working under those circumstances. You would simply define it to work = if the compiler chooses to execute the function at compile time
<= br>
I am quoting Eric from this issue which mentions ODR violatio= ns as a potential issue:=C2=A0https://gcc.gnu.org/bugzilla/show_bug.cgi?id= =3D79452

>There are definitely opportunities for ODR vi= olations here, or at least
>something like them. Consider the follow= ing case:
>
= >temp= late <class T>
>constexpr bool foo(T) {
> =C2=A0if constexpr(__ctfe__)
> =C2=A0 =C2=A0return tr= ue;
= > =C2= =A0else
>= =C2=A0 =C2=A0return false
>}
>
>static_assert(foo(0));
>auto runtime =3D foo(0);
>
>Both calls instantiate foo with the same t= emplate arguments, so they should
>seemingly both get the same instantiation with th= e w/e value of `__ctfe__` was
>when the implicit instantiations occurred. Therefore = one of the two calls to
>foo() will return the wrong answer.
>
>This problem is made ever worse if `_= _builtin_constant_expression` allows you
>to generate non-dependent compile-time expressions b= ased on the function
>arguments.
>
>One solution would be to consider the instantiation of `foo` to b= e value
>= dependent on a "implicit template parameter" representing `__ctfe= __`.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/34826fd2-84db-4ce9-b30b-66a95601918a= %40isocpp.org.
------=_Part_1005_2054971813.1486838634069-- ------=_Part_1004_293586593.1486838634069-- .