220 30831 <86a47916-27c3-4e29-862f-9b4e1f105c1c@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Gonzalo BG Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Detecting compile-time evaluation Date: Thu, 9 Feb 2017 05:19:26 -0800 (PST) Lines: 124 Approved: news@gmane.org Message-ID: <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_204_429265247.1486646366897" X-Trace: blaine.gmane.org 1486646372 7533 195.159.176.226 (9 Feb 2017 13:19:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 9 Feb 2017 13:19:32 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDTOBQEKX4PRBX6Y6HCAKGQEO5LQSZA@isocpp.org Thu Feb 09 14:19:24 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f69.google.com ([209.85.213.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cbod8-0001Nx-Pu for gclcip-std-proposals@m.gmane.org; Thu, 09 Feb 2017 14:19:22 +0100 Original-Received: by mail-vk0-f69.google.com with SMTP id 23sf1884631vkc.1 for ; Thu, 09 Feb 2017 05:19:28 -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: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=kchg61tkUN6/kLXbUe4E16r58TYAIJ6TaI49UsZQ/y4=; b=iCaqRyf+8Q9rjRrkaU71QrCkobF9buRxK16V/fSiU3zjRNv607Rw9bX76BxKxUeTBB UPcoaotWTFL5H9m0MlGrlvekwf6oXMMWpO3HKM0rJGhSbvPZBIoW4Fnc03nl0jZSDR28 iTsAM4xAHIa+sJPce9QplFxpQWN+HIuER/w0kh67fhkHNqubX8r05E9UYfvFCt9zM/iD hO8aarDgMDktvoCpAJbe/uqXrNQawrYfN9W92MoeQCfYYSWMu8zQw+sv0mmvUFLBcsQ9 FaOiIxA9eohfBzysxv4tK64OavbsctBJlAR3uin5rQQj6IcH/vPUpkyUZJaewTUfc2AS 5Brw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id: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=kchg61tkUN6/kLXbUe4E16r58TYAIJ6TaI49UsZQ/y4=; b=LjMeQ799zyBAncSDJNKlULRgVobtdp18sFgwDULrUeYP1X1xwbMKKeqmn9nokRVhfH NXcso6ybPo7stUCk+5/FJn8O6WLLRsDuW2L694Z0vArD3EIshnQdwRoGWO6i5633s5nv jaBVUiUOopoZsW90x6HeAmR2GX1EY1SdtyjCeR3t02a4b9E3JbKUQ3K33Mc+zB/GIDDg 864dyKbgLtUIMtfhyee8jIrPpyp+MXSFgm/ohD4Z+BzDh44fdmUjoraZmYSksaX+ko91 MvbBgiUHiNBA217Oj/KnwmSYJXUUuaFCIy4YYBzP7DD7pbHU/xXJ/ovtIzVmRIyfyK2y D9kg== 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: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=kchg61tkUN6/kLXbUe4E16r58TYAIJ6TaI49UsZQ/y4=; b=GR7AL3ls5ZIvAQ94VbGfhmnocewxvh54hHS0WFaOBFLm2QZf+DzoPA5T27fzIWpJNv C0i8uDATZW4jLdwj75IcOa9z2ZOxWeW76ywQ71fO01LSXpP7srMKVrNVCsR12wBrrWZE ZGbxH/5nD5mR/AiGqkpaDoRjfE5cT9glDOzUtVRnIqBd1K9hLDHwXm+tUx1qaXusassB fzM9GVA2GzQjzVv0My8LgLEtgeoQRi8MUxBv9+AfGDfnHFa+cg8oxK1ZwPVlfAkRTSnK s7h5ol8CCg58w9Pt6QAtmS46EwMPCXHg3ioZxX1yotuBH2UBd0ofUmVl5XibWHeZfGgw v5ZQ== X-Gm-Message-State: AMke39mpjREVGtOntAShf4F8bF/5nvshLy3qICL9XAn05CkJW113fw/kSK+JVGKNU1AAxg== X-Received: by 10.176.85.135 with SMTP id v7mr741503uaa.8.1486646368122; Thu, 09 Feb 2017 05:19:28 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.40.214 with SMTP id s80ls21516479ota.11.gmail; Thu, 09 Feb 2017 05:19:27 -0800 (PST) X-Received: by 10.157.39.202 with SMTP id c68mr122354otb.8.1486646367357; Thu, 09 Feb 2017 05:19:27 -0800 (PST) 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:30831 Archived-At: ------=_Part_204_429265247.1486646366897 Content-Type: multipart/alternative; boundary="----=_Part_205_2061782630.1486646366897" ------=_Part_205_2061782630.1486646366897 Content-Type: text/plain; charset=UTF-8 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. There is also prior art in the D language, where the __ctfe intrinsic is provided [3], and quoting its documentation, defined as: > The __ctfe boolean pseudo-variable, which evaluates to true at compile time, but false at run time, can be used to provide an alternative execution path to avoid operations which are forbidden at compile time. Every usage of __ctfe is evaluated before code generation and therefore has no run-time cost, even if no optimizer is used. [0] https://drive.google.com/file/d/0B0-xyi_NILkZeUxCWjdudW52UjQ/view [1] https://groups.google.com/a/isocpp.org/forum/?fromgroups#!searchin/std-proposals/constexpr$20overloading/std-proposals/1MxiNSeJAj8/s4BXtHnA_pwJ [3] http://dlang.org/spec/function.html -- 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/86a47916-27c3-4e29-862f-9b4e1f105c1c%40isocpp.org. ------=_Part_205_2061782630.1486646366897 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
AFAIK none of the major C++ compilers provide a way to det= ect whether a constexpr function is being evaluated at compile-time.
This is unfortunate. I have a constexpr function with bad run-time perform= ance. Rewriting it to use SSE4.2 intrinsics improves its performance by 3.5= x. Those intrinsics are not constexpr functions. I could imagine similar si= tuations in which one would need to go down to inline assembly to deliver a= cceptable run-time performance in constexpr functions. Inline assembly cann= ot be neither standardized nor evaluated at compile-time.=C2=A0

So I= must choose: either constexpr (which my function already was) but horrible= run-time performance, or run-time performance and breakage (because my fun= ction was already constexpr). This is an uncomfortable spot to be in. In pa= rticular, since constexpr functions are not limited to compile-time evaluat= ion.

There are some unreliable hacks to workaround this. For example= using GCC, if all arguments of a function are "__builtin_constant_p(a= rg) =3D=3D true", chances are that the function is being evaluated at = compile-time. Obviously, this hack is neither reliable nor portable.=C2=A0<= br>
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 tha= t faster run-time algorithms can be implemented without hacks, than offerin= g a escape hatch. I don't see how this could ever work for somebody wan= ting 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 th= at a standard library function, "constexpr bool std::is_context_being_= constant_evaluated();", would be a simple addition to the language tha= t solves all the needs to differentiate between run-time and compile-time c= ode in constexpr functions. It does not have any of the complications of a = new constexpr overloading mechanism.=C2=A0

There is also= prior art in the D language, where the __ctfe intrinsic is provided [3], a= nd quoting its documentation, defined as:
> The __ctfe boolean pseudo= -variable, which evaluates to true at compile time, but false at run time, = can be used to provide an alternative execution path to avoid operations wh= ich are forbidden at compile time. Every usage of __ctfe is evaluated befor= e code generation and therefore has no run-time cost, even if no optimizer = is used.

[0]=C2=A0https://drive.google.com/file= /d/0B0-xyi_NILkZeUxCWjdudW52UjQ/view
[1]=C2=A0https://groups.goog= le.com/a/isocpp.org/forum/?fromgroups#!searchin/std-proposals/constexpr$20o= verloading/std-proposals/1MxiNSeJAj8/s4BXtHnA_pwJ
[3]= =C2=A0http://dlang.org/spec/function.html

--
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/86a47916-27c3-4e29-862f-9b4e1f105c1c= %40isocpp.org.
------=_Part_205_2061782630.1486646366897-- ------=_Part_204_429265247.1486646366897-- .