220 30835 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Detecting compile-time evaluation Date: Thu, 9 Feb 2017 07:21:22 -0800 (PST) Lines: 128 Approved: news@gmane.org Message-ID: 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_251_216376776.1486653682496" X-Trace: blaine.gmane.org 1486653684 13811 195.159.176.226 (9 Feb 2017 15:21:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 9 Feb 2017 15:21:24 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBB44R6LCAKGQEQUIE5II@isocpp.org Thu Feb 09 16:21:20 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ot0-f199.google.com ([74.125.82.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cbqX8-0003Bw-L5 for gclcip-std-proposals@m.gmane.org; Thu, 09 Feb 2017 16:21:18 +0100 Original-Received: by mail-ot0-f199.google.com with SMTP id 65sf6731560otq.2 for ; Thu, 09 Feb 2017 07:21:24 -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=y4I/Dabmea4kFMj+7sdm5q6J7zN4VMab67Z1shJeRnc=; b=xmRsYc6G+HDlKuLZlCHaaXlKBgqxXVNQ27fI21ACajJZJBROni8s29XESxorA5k5od Mlt2LEhPqbFOiyumYu841h63nxkHAc/ndmMIcV3TcfAFzoziybQCCyHzQhm2/0aU8+Os d/0zW+dc2nymbrq3QYA065434qk0aYPQZioYY733JbW0YMmltYuuT1MRWXFGNR8CxkfX Zs7qxUZXtzeRQkgzeyAEwL6sr80uPBEWTxJPW0SM3E0w84uAI1Wev56spNz4rLnDOYwW f0Koq2rrBVBbvDZ6cOoiVmDDetbwtzbFlSnkhTBw31ibCMS1J9/qB0nTQfTNX/URyBcb bkBg== 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=y4I/Dabmea4kFMj+7sdm5q6J7zN4VMab67Z1shJeRnc=; b=fGzMeAUExxgNr9bwAA/xkRwrXlFU94QMMqVXys4vs9co8e5VYamGUvy7tkXmtkkuPQ 4ypd8JRoz4cXLe2/GdsAZKVq2JdWxkNGp7voGbxj3rTS6JcQkme24CMbG2h+5woi911x lj8F3uw/bEvZX1aRTFCiXNwg1kCf4yCIM0TtHesPcAo/nsnDS/49s0BLbaPSvd2wXQH5 pjrPyzUUicu9Tuar69gLQiyJIWKAnPb9paMe5insQ9DTpcQ43DpxAtQEV6IjmdBJBH0t BnaLGtmOraWhyS8mod6Ti5JlrVlsRn7gBnd+8AnvCnLGkq9p8EpwE1JQK7RGFDKLHdHZ N9Qg== 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=y4I/Dabmea4kFMj+7sdm5q6J7zN4VMab67Z1shJeRnc=; b=RB8YhZK5rFyzP4D6ZTjrsQPJZ7rpRBMDfLr+J3HywU+6Tuh9vzN/gK61ynzfDOOwyB /3fyTQo407eS3pLMYxa3HEl7lr4tBhr8pOCuycin1gsoiemEZltrfzcngERA+soVKa/y 8rAI18Tmj+BHVQAIDPCFd0jziXz4h+EQAyGKqC1rpi7kCdpyPQdUNam0r9NA4t79NUdS lInqP3Ez39C6OA4OVW/TDwOC32BqFkjkJwN2yUzR7pnVpGLTTU3KatFm3GMKtoSPIchm /CBlGH0jwCjX7MlamfuTpMZLevEm8hU+WRRAm4n7IcH2fa7ye+3c4c28G2sr3mUGlfkA ZMIQ== X-Gm-Message-State: AMke39kPJhaQustwcNdlhFN+KjREHZZura+5xAcWacZq/jhN1Yvum4qPBmHrRrtPULS21w== X-Received: by 10.157.17.78 with SMTP id p14mr1131358otp.4.1486653683950; Thu, 09 Feb 2017 07:21:23 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.10.196 with SMTP id 62ls23454139otq.7.gmail; Thu, 09 Feb 2017 07:21:23 -0800 (PST) X-Received: by 10.157.8.10 with SMTP id 10mr193647oty.19.1486653683096; Thu, 09 Feb 2017 07:21:23 -0800 (PST) In-Reply-To: <86a47916-27c3-4e29-862f-9b4e1f105c1c@isocpp.org> X-Original-Sender: jmckesson@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:30835 Archived-At: ------=_Part_251_216376776.1486653682496 Content-Type: multipart/alternative; boundary="----=_Part_252_1409025950.1486653682496" ------=_Part_252_1409025950.1486653682496 Content-Type: text/plain; charset=UTF-8 On Thursday, February 9, 2017 at 8:19:27 AM UTC-5, Gonzalo BG wrote: > > AFAIK none of the major C++ compilers provide a way to detect whether a > constexpr function is being evaluated at compile-time. > > This is unfortunate. I have a constexpr function with bad run-time > performance. Rewriting it to use SSE4.2 intrinsics improves its performance > by 3.5x. Those intrinsics are not constexpr functions. I could imagine > similar situations in which one would need to go down to inline assembly to > deliver acceptable run-time performance in constexpr functions. Inline > assembly cannot be neither standardized nor evaluated at compile-time. > > So I must choose: either constexpr (which my function already was) but > horrible run-time performance, or run-time performance and breakage > (because my function was already constexpr). This is an uncomfortable spot > to be in. In particular, since constexpr functions are not limited to > compile-time evaluation. > > There are some unreliable hacks to workaround this. For example using GCC, > if all arguments of a function are "__builtin_constant_p(arg) == true", > chances are that the function is being evaluated at compile-time. > Obviously, this hack is neither reliable nor portable. > > Some people have particularly argued for "constexpr overloading" and other > complicated features in the past [0, 1]. The main argument against those > was that the committee preferred to improve constexpr so that faster > run-time algorithms can be implemented without hacks, than offering a > escape hatch. I don't see how this could ever work for somebody wanting to > use inline assembly for the run-time implementation of a constexpr > function, and hence argue that we do need a escape hatch. > > I think that a standard library function, "constexpr bool > std::is_context_being_constant_evaluated();", would be a simple addition to > the language that solves all the needs to differentiate between run-time > and compile-time code in constexpr functions. It does not have any of the > complications of a new constexpr overloading mechanism. > I think there's a much easier way: `if constexpr`. As it currently stands, `if constexpr()` is a compile error, since there is no expression to evaluate. What if we make it so that `if constexpr()` means "if I'm in a constant expression evaluation". And thus, the `else` clause would be "if I'm not in a constant expression evaluation". After all, 90% of the time you're going to call `is_context_being_constant_evaluated`, you're going to use it in an `if constexpr` statement. So let's just skip the middleman. -- 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/f8a6ac63-391f-4b21-b4e2-e70f333b554d%40isocpp.org. ------=_Part_252_1409025950.1486653682496 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thursday, February 9, 2017 at 8:19:27 AM UTC-5,= Gonzalo BG wrote:
AFAIK none of the major C++ compilers provide a way to detect whether = a constexpr function is being evaluated at compile-time.

This is unf= ortunate. I have a constexpr function with bad run-time performance. Rewrit= ing it to use SSE4.2 intrinsics improves its performance by 3.5x. Those int= rinsics are not constexpr functions. I could imagine similar situations in = which one would need to go down to inline assembly to deliver acceptable ru= n-time performance in constexpr functions. Inline assembly cannot be neithe= r standardized nor evaluated at compile-time.=C2=A0

So I must choose= : either constexpr (which my function already was) but horrible run-time pe= rformance, or run-time performance and breakage (because my function was al= ready constexpr). This is an uncomfortable spot to be in. In particular, si= nce constexpr functions are not limited to compile-time evaluation.

= There are some unreliable hacks to workaround this. For example using GCC, = if all arguments of a function are "__builtin_constant_p(arg) =3D=3D t= rue", chances are that the function is being evaluated at compile-time= .. Obviously, this hack is neither reliable nor portable.=C2=A0

Some = people have particularly argued for "constexpr overloading" and o= ther complicated features in the past [0, 1]. The main argument against tho= se was that the committee preferred to improve constexpr so that faster run= -time algorithms can be implemented without hacks, than offering a escape h= atch. I don't see how this could ever work for somebody wanting to use = inline assembly for the run-time implementation of a constexpr function, an= d hence argue that we do need a escape hatch.

I think that a standar= d library function, "constexpr bool std::is_context_being_constan= t_evaluated();", would be a simple addition to the language that solve= s all the needs to differentiate between run-time and compile-time code in = constexpr functions. It does not have any of the complications of a new con= stexpr overloading mechanism.

I think there'= s a much easier way: `if constexpr`.

As it currently stands, `if con= stexpr()` is a compile error, since there is no expression to evaluate. Wha= t if we make it so that `if constexpr()` means "if I'm in a consta= nt expression evaluation". And thus, the `else` clause would be "= if I'm not in a constant expression evaluation".

After all,= 90% of the time you're going to call `is_context_being_constant_evalua= ted`, you're going to use it in an `if constexpr` statement. So let'= ;s just skip the middleman.

--
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/f8a6ac63-391f-4b21-b4e2-e70f333b554d= %40isocpp.org.
------=_Part_252_1409025950.1486653682496-- ------=_Part_251_216376776.1486653682496-- .