220 30870 <18849693.bqFcfaDNcV@tjmaciei-mobl1> article Path: news.gmane.org!.POSTED!not-for-mail From: Thiago Macieira Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Detecting compile-time evaluation Date: Sat, 11 Feb 2017 12:35:29 -0800 Lines: 82 Approved: news@gmane.org Message-ID: <18849693.bqFcfaDNcV@tjmaciei-mobl1> References: <86a47916-27c3-4e29-862f-9b4e1f105c1c@isocpp.org> <34826fd2-84db-4ce9-b30b-66a95601918a@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 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1486845338 6075 195.159.176.226 (11 Feb 2017 20:35:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 11 Feb 2017 20:35:38 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCB4TK757YBRBF7L7XCAKGQECJHGXOQ@isocpp.org Sat Feb 11 21:35:33 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f71.google.com ([209.85.215.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cceOK-0001Gv-FN for gclcip-std-proposals@m.gmane.org; Sat, 11 Feb 2017 21:35:32 +0100 Original-Received: by mail-lf0-f71.google.com with SMTP id j90sf27630394lfi.3 for ; Sat, 11 Feb 2017 12:35:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-transfer-encoding:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=mw2L3KsUyx1+iblJk5jEzjYz1v6Fkaez/Gho4WAxBVA=; b=srwtfP+TrO+z09/HWrN7JXgmGhL42OalRqA/ad2UMLW8/upAx3CPH6jrItN5A86VhU RFQy3A1j3XWAFSIdnSdOTGaGhneRizB9PK2MAQk4xdAvxZi4GL8i9poeO0OvIzocerU/ EofAGjnGna4WkmxJ2Y72VN7ejnExgZQs1x5uBknecv3QeXRn8eeN0r1RM1sG25+1Gu73 DADSNA642dnfmBSsLnhTFtJ5X1tJn8bRISi+qokjgi3zVFjplktH7+RdDuBguHaw2WhP /7UdNfUlAknHGy5+rLkFtBifsxTHSKQm8btqNdBQ02d2zSpegYaQDTkzUT+9t1YxpN+R Itug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=mw2L3KsUyx1+iblJk5jEzjYz1v6Fkaez/Gho4WAxBVA=; b=nOMQ4u5RzRiZqJGdDjKI6D8CeTdbNRpuhCquKNAawV4v2SL3446ClXKty19Fy9iikj SbRiNx9Ik1udI3xQbzH+2ZHv4guakAxVXyAjLueTTLQk/hENF4NN/sTf3EMBhkzPEu2v BLSV9IJoNTgzcCPPC0A7r8qvz0uw/WZQMsrdCpMb006hXLak8JR1dKsYNtzB41lCCWlE 9fr3ZgMFf39F2sZanY8qiA4u31DXVs9SGViWNdX/1oivcf4h7xyCmWPIE87LDRzSNoup FIm3tyDliQHMIlgE2oL52jwMYY/56KAbknHwKrmDcyd5ktfomMko6rdRzL7ViAzNWJwR INX X-Gm-Message-State: AMke39lN+yCjAHnjWQw1Gg31hzfbLDGqJOOj0rmY/QuW33a7GCdwV9ps1bbS6wRIMZxwdQ== X-Received: by 10.46.87.92 with SMTP id r28mr1635678ljd.15.1486845338242; Sat, 11 Feb 2017 12:35:38 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.45.87 with SMTP id t84ls267659wmt.27.gmail; Sat, 11 Feb 2017 12:35:35 -0800 (PST) X-Received: by 10.223.153.144 with SMTP id y16mr12646444wrb.81.1486845332701; Sat, 11 Feb 2017 12:35:32 -0800 (PST) Original-Received: from gondolin.macieira.info (gondolin.macieira.info. [78.47.120.188]) by mx.google.com with ESMTP id 74si6284016wme.29.2017.02.11.12.35.32 for ; Sat, 11 Feb 2017 12:35:32 -0800 (PST) Received-SPF: pass (google.com: domain of thiago@macieira.org designates 78.47.120.188 as permitted sender) client-ip=78.47.120.188; Original-Received: from tjmaciei-mobl1.localnet (c-24-20-209-24.hsd1.or.comcast.net [24.20.209.24]) by gondolin.macieira.info (Postfix) with ESMTPSA id 98EDF11B604 for ; Sat, 11 Feb 2017 12:35:31 -0800 (PST) In-Reply-To: <34826fd2-84db-4ce9-b30b-66a95601918a@isocpp.org> X-Original-Sender: thiago@macieira.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of thiago@macieira.org designates 78.47.120.188 as permitted sender) smtp.mailfrom=thiago@macieira.org 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:30870 Archived-At: On s=C3=A1bado, 11 de fevereiro de 2017 10:43:53 PST Gonzalo BG wrote: > @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. >=20 > Given that you have run into the issue, I cannot find the logic in the >=20 > following statement: > > But in our experience, any algorithm that can be complex enough to > > warrant SIMD optimisation is too complex for a constexpr inline functio= n. >=20 > You seem to be arguing that using __builtin_ctz in a constexpr function i= s > 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? It was a problem, but it's now fixed and we now can use the builtin that is= =20 constexpr. > 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, bu= t > this did not solve the underlying issue (which is being discussed here). That's an interesting example, but it doesn't match my experience. I haven'= t=20 seen a lot of people need exponentiation and logarithm in constexpr constex= ts.=20 In regular code, you simply rely on the optimiser propagating constants,=20 something compilers have done for a decade. > 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 intrinsi= cs > (and pragmas and what not) for run-time performance reasons. Same as above: I've never seen the need for those operations to appear in a= =20 constexpr context in the first place. It is as I said: the majority of the= =20 operations that benefit from non-constexpr'able code is too complex for=20 constexpr anyway. > Do you consider using a log function (which is implemented using intrinsi= cs > in most standard libraries) or multiplying two 4x4 matrices "too complex" > for constexpr functions? Yes, in my experience. Or, put another way, what use-case warrants storing the result of such an= =20 operation in a constexpr variable? This is a real question, you probably kn= ow=20 more cases than I do. --=20 Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center --=20 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 e= mail 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/18849693.bqFcfaDNcV%40tjmaciei-mobl1. .