220 30836 article Path: news.gmane.org!.POSTED!not-for-mail From: Faisal Vali Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Detecting compile-time evaluation Date: Thu, 9 Feb 2017 09:24:09 -0600 Lines: 80 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: text/plain; charset=UTF-8 X-Trace: blaine.gmane.org 1486653883 20699 195.159.176.226 (9 Feb 2017 15:24:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 9 Feb 2017 15:24:43 +0000 (UTC) To: "" Original-X-From: std-proposals+bncBDDKRIXX5YARBOET6LCAKGQEGKZYA5Y@isocpp.org Thu Feb 09 16:24:37 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f197.google.com ([209.85.192.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cbqaK-00052Z-9g for gclcip-std-proposals@m.gmane.org; Thu, 09 Feb 2017 16:24:36 +0100 Original-Received: by mail-pf0-f197.google.com with SMTP id 204sf9230762pfx.1 for ; Thu, 09 Feb 2017 07:24:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:x-original-sender:x-original-authentication-results :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=bN5PDGA6kJh/iKQR40Ti+JPep1JljCIr6M1AbGKdW/I=; b=P4dfBNLA0L6GPtePazx9sdpicc4T742Oab8fwG0ml+Ml0MjOWxc0Ha62/cY2MHSFYO VgK8jHK07BZl5uYx77+uX5ALEGzDHY3qsP8CSmZ1fDTDyYPMgGsLe+WX15pyCi/EE6Qi Y3qDIKdv2mpdHefcQDaj0+5XPi57/K6Fav/msZd2r33y2mqAj+LBHSRqUpShWdSi6wyL +L/n2MeBJqeVd2lB2p2BLPZL6U6fFrDOZyJXxJK9L1qQMAXjPe5uEDx2ijGsACA1kv/k n66Ztys0bdqfaJ20NpfHOsGF6L0+l4nuJMthewcwxUPtcgW+v101IkEjCaU0yntOPQSn 5H0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:x-original-sender :x-original-authentication-results:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=bN5PDGA6kJh/iKQR40Ti+JPep1JljCIr6M1AbGKdW/I=; b=ZoS4DCudGne7H6PmDpBdl9pFq4BWn/U28OaZjogi6wlWreVbdM8SXq06sVPP2miRf9 nKeQNBr40Omx3Ukz/DLv6obv2HYoc9gTcFek0qbI/GimTvsQqQgC+S7Gm512yXzgUrtJ FkEKq5daaQnAq9SQC2Px4tXHrVMmbh3aqo50xD/AZm61Krnx4KYpzm7Y8YQAKa9n8IxV W+n+VKtpJxYpNVobNKYw1MEqqnPdkh1xxTNP0oG71kma87eKzkP/PVqupETZ2Wg8kE2q o4bAInXnHWWvfp4auYMnPQjlfJKgl0YuAduY/WuhOfgurMma2gKky5eCveb6uARjkY8m rqyw== X-Gm-Message-State: AMke39lYjGl0rmx9iskqatyVs7LSwH7pORVGwNiReSMug/56AuImIgH011ORywyHop7usw== X-Received: by 10.99.6.137 with SMTP id 131mr1207291pgg.9.1486653881219; Thu, 09 Feb 2017 07:24:41 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.20.230 with SMTP id r35ls20558939otr.25.gmail; Thu, 09 Feb 2017 07:24:40 -0800 (PST) X-Received: by 10.157.27.169 with SMTP id z38mr1885972otd.262.1486653880492; Thu, 09 Feb 2017 07:24:40 -0800 (PST) Original-Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com. [2607:f8b0:4003:c0f::235]) by mx.google.com with ESMTPS id i21si4778731otd.86.2017.02.09.07.24.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 07:24:40 -0800 (PST) Received-SPF: pass (google.com: domain of faisalv@gmail.com designates 2607:f8b0:4003:c0f::235 as permitted sender) client-ip=2607:f8b0:4003:c0f::235; Original-Received: by mail-ot0-x235.google.com with SMTP id 65so5364299otq.2 for ; Thu, 09 Feb 2017 07:24:40 -0800 (PST) X-Received: by 10.157.46.67 with SMTP id c3mr2084212otd.163.1486653879884; Thu, 09 Feb 2017 07:24:39 -0800 (PST) Original-Received: by 10.157.56.229 with HTTP; Thu, 9 Feb 2017 07:24:09 -0800 (PST) In-Reply-To: <86a47916-27c3-4e29-862f-9b4e1f105c1c@isocpp.org> X-Original-Sender: faisalv@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of faisalv@gmail.com designates 2607:f8b0:4003:c0f::235 as permitted sender) smtp.mailfrom=faisalv@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=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:30836 Archived-At: IMHO, if you have a valid use case that improves the performance of your code (and resonates with "enough" domain experts) - yet is very challenging (if not impossible) to implement in current C++, we should at the very least strongly consider providing it as an extension in clang (which I believe should not be hard to implement - i.e. codegen ignores the true-branch, and Richard's expression evaluator ignores the false-branch). Whether the standardization committee will ever embrace it (following a paper), is quite another matter (and might depend on the quality and reputation of the code-bases that emerge around it) ... Faisal Vali On Thu, Feb 9, 2017 at 7:19 AM, 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. > > 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. -- 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/CABsSTho9bW015Eo7KNEBoYs2snREYJYzn6SdQGjYMy64zZETnA%40mail.gmail.com. .