220 17327 article Path: news.gmane.org!not-for-mail From: Alexander Marinov Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: constexpr function arguments Date: Sun, 12 Apr 2015 06:13:35 -0700 (PDT) Lines: 490 Approved: news@gmane.org Message-ID: References: <1799313.qMEWgUf3zn@lastique-pc> <2811449.Gbl9WO8oH6@lastique-pc> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_223_1997393265.1428844415939" X-Trace: ger.gmane.org 1428844419 9332 80.91.229.3 (12 Apr 2015 13:13:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 12 Apr 2015 13:13:39 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDBNZXHN2QPRBAG7VGUQKGQEVAFYSYQ@isocpp.org Sun Apr 12 15:13:39 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f70.google.com ([209.85.218.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YhHhi-0002EG-OT for gclcip-std-proposals@m.gmane.org; Sun, 12 Apr 2015 15:13:39 +0200 Original-Received: by oihf133 with SMTP id f133sf48633041oih.3 for ; Sun, 12 Apr 2015 06:13:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=6UcIgk0FtgvnX49UhJy2wKZU2sA5aJeNHB6TVoB4Ew0=; b=OCV36xhORxCdn5aYX6LDw70QE8ORqypaVHJ/lRY90aYzW7xSmKom4uW7kOaDcIFxBX RBn/pMBZINTt8ZfcIvLlJsjdJNNPbJyzAeuSp8wBD76WuJAbcrhMLXkXjZet3stk/pWB m03VC1Xx/WSqtLPbGBDcaH1WXlOq5bjAUarh/zMRlL/WFk0/nB3wxCSanrkWR8dduzqV Zf9M4B7QMAvT+GKT6SOpjyAuUibMwPy0cROJuFvskjue/kg7qh06LGyivm/Ev81BnlLs kLaidMQz6BhowHat2r5FSfw3K8h71MCSTbnA1Oh7+m2CF31vWjzFu7aCaFODT0lenAag ooyA== X-Gm-Message-State: ALoCoQm68IaOUeRTskIio3CKnkFMmLti2+1idScGpiGGHA+zhtnP8NLiAyow2SIgr1imD7hMP5Ak X-Received: by 10.182.74.228 with SMTP id x4mr14304885obv.14.1428844417230; Sun, 12 Apr 2015 06:13:37 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.91.65 with SMTP id y59ls2266884qgd.43.gmail; Sun, 12 Apr 2015 06:13:36 -0700 (PDT) X-Received: by 10.140.25.147 with SMTP id 19mr123207qgt.0.1428844416550; Sun, 12 Apr 2015 06:13:36 -0700 (PDT) In-Reply-To: <2811449.Gbl9WO8oH6@lastique-pc> X-Original-Sender: sasho648@mail.bg 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:17327 Archived-At: ------=_Part_223_1997393265.1428844415939 Content-Type: multipart/alternative; boundary="----=_Part_224_724234951.1428844415939" ------=_Part_224_724234951.1428844415939 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You read my proposal - it does the same thing you want even if you don't=20 fully understand it. Actually 'constexpr' is a useless keyword - it adds nothing to 'inline'=20 functions which most compilers already optimize out and evaluate at=20 compile-time if possible. Much better will be the properties to 'constexpr'= =20 to be automatically added to each inline function. And what are they=20 actually? An 'constexpr' function may be evaluated at compile-time (so do 'inline'). An 'constexpr' function may be used at a constant-expression and if so -=20 it's required to be evaluated at compile-time. Actually the second line is the so 'BIG' difference between those two but I= =20 think that it can be implicitly applied to all 'inline' functions without= =20 any issues (performance or whatever). The part which fulfill your idea is 'inline' variables which are guaranteed= =20 to be evaluated at run-time (as template parameters) and more specially=20 'inline' function parameters (which imply that the function they=20 declare/define is 'inline' because templates can't be defined at different= =20 TU). So your example will look like this by using my construct: template< typename T >=20 void atomic::store(T val, inline memory_order order)=20 {=20 switch (order) // order is always constexpr=20 {=20 // implementations with different memory ordering guarantees=20 }=20 } With the exact same semantics you want. Function parameter 'order' will=20 accept only constant-expressions and it will be evaluated at compile-time.= =20 Actually those semantics are possible now too but have different=20 syntax(etc. by using template parameters): template< typename T, memory_order order >=20 void atomic::store(T val)=20 {=20 switch (order) // order is always constexpr=20 {=20 // implementations with different memory ordering guarantees=20 }=20 } =D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 12 =D0=B0=D0=BF=D1=80=D0=B8=D0=BB 201= 5 =D0=B3., 15:29:21 UTC+3, Andrey Semashev =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0: > > On Sunday 12 April 2015 05:09:29 Alexander Marinov wrote:=20 > > I already sketched the details of this idea. You can read it here=20 > > < > https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/RTss7U= yl=20 > > zgQ>. Only someone needs to write a proposal and/or implement it as a= =20 > demo=20 > > in some open-source compiler (GCC or Clang).=20 > > No, I don't think your proposal is related to my idea. I'm not trying to= =20 > make=20 > a function constexpr, I'm trying to propagate compile-time nature of some= =20 > of=20 > its arguments to its body, which is executed in run time.=20 > > (offtopic: And I do think that inline and constexpr are different=20 > properties=20 > of the code, even though they are somewhat related on the implementation= =20 > side;=20 > I do not think they should be mixed together in a single keyword.)=20 > > > =D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 12 =D0=B0=D0=BF=D1=80=D0=B8=D0=BB= 2015 =D0=B3., 13:33:17 UTC+3, Andrey Semashev =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0:=20 > > > Hi,=20 > > >=20 > > > I wonder if constexpr function arguments would be a useful addition t= o=20 > the=20 > > >=20 > > > standard. Consider this part of std::atomic interface:=20 > > > template< typename T >=20 > > > void atomic::store(T val, memory_order order)=20 > > > {=20 > > > =20 > > > switch (order)=20 > > > {=20 > > > =20 > > > // implementations with different memory ordering guarantees=20 > > > =20 > > > }=20 > > > =20 > > > }=20 > > >=20 > > > The function itself is not constexpr because the implementation has a= =20 > > > runtime=20 > > > side effect. However the memory order argument is always constant in= =20 > > > normal=20 > > > uses and the implementation could have had benefitted from knowing=20 > this=20 > > > constant at compile time. The current standard does not offer means= =20 > for=20 > > > that,=20 > > > so you're out of luck if the compiler is not smart enough to propagat= e=20 > > > this=20 > > > constexpr hint behind the scenes. For the most part with compilers I= =20 > have=20 > > > experience with (gcc, icl, msvc) this only works when the compiler is= =20 > able=20 > > > to=20 > > > inline the function call.=20 > > >=20 > > > BTW, if anyone wonders if compiler intrinsics help here, no they=20 > don't.=20 > > > With=20 > > >=20 > > > the code similar to this:=20 > > > template< typename T >=20 > > > void atomic::store(T val, memory_order order)=20 > > > {=20 > > > =20 > > > __atomic_store_n(&m_value, val, order);=20 > > > =20 > > > }=20 > > >=20 > > > gcc and icl simply fall back to memory_order_seq_cst regardless of th= e=20 > > > specified order if they cannot inline the function. This always=20 > happens in=20 > > > debug, for instance.=20 > > >=20 > > > What I'm thinking is if we could require some argument to be constexp= r=20 > and=20 > > > pass that 'compile-timeness' hint to the function body, the=20 > implementation=20 > > >=20 > > > could optimize better. For example:=20 > > > template< typename T >=20 > > > void atomic::store(T val, constexpr memory_order order)=20 > > > {=20 > > > =20 > > > switch (order) // order is always constexpr=20 > > > {=20 > > > =20 > > > // implementations with different memory ordering guarantees=20 > > > =20 > > > }=20 > > > =20 > > > }=20 > > >=20 > > > In this case the switch/case would always be optimized to a single=20 > case.=20 > > > And=20 > > > the intrinsic-based version would also work as intended. Also, if we= =20 > have=20 > > > a=20 > > > non-constexpr overload of this function we would also support calling= =20 > with=20 > > > a=20 > > > runtime value of the memory order (not that it would be of much use= =20 > > > though).=20 > > >=20 > > > I understand this would have consequences on the ABI because constexp= r=20 > > > arguments essentiall require to duplicate the function body for each= =20 > > > constant=20 > > > argument value. It's not a big problem though because we already do= =20 > that=20 > > > for=20 > > > non-type template parameters.=20 > > >=20 > > > Opinions?=20 > > --=20 ---=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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. ------=_Part_224_724234951.1428844415939 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You read my proposal - it does the same thing you want eve= n if you don't fully understand it.

Actually 'constexpr'= is a useless keyword - it adds nothing to 'inline' functions which most co= mpilers already optimize out and evaluate at compile-time if possible. Much= better will be the properties to 'constexpr' to be automatically added to = each inline function. And what are they actually?

= An 'constexpr' function may be evaluated at compile-time (so do 'inline').<= /div>

An 'constexpr' function may be used at a constant-= expression and if so - it's required to be evaluated at compile-time.
=


Actually the second line is the so 'BIG'= difference between those two but I think that it can be implicitly applied= to all 'inline' functions without any issues (performance or whatever).

The part which fulfill your idea is 'inline' variabl= es which are guaranteed to be evaluated at run-time (as template parameters= ) and more specially 'inline' function parameters (which imply that the fun= ction they declare/define is 'inline' because templates can't be defined at= different TU).

So your example will look like thi= s by using my construct:

tem= plate<<= /span> typename T >
  void atomic<T>::store(T val, inline memory_order order= )
  {
    switch (order) // order is always constexpr
    {
      // implementations with different m= emory ordering guarantees
    }

  }

With the exact sam= e semantics you want. Function parameter 'order' will accept only constant-expressions and it will be evaluated at comp= ile-time. Actually those semantics are possible now too but have different = syntax(etc. by using template parameters):

templ= ate< typename T, memory_order order >
  void atomic<T>::store(T = val)
  {
    switch<= span style=3D"color: #000;" class=3D"styled-by-prettify"> (order) // order is always constexpr
    {
      // implementations with d= ifferent memory ordering guarantees
    }

  }

=D0=BD= =D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 12 =D0=B0=D0=BF=D1=80=D0=B8=D0=BB 2015 =D0= =B3., 15:29:21 UTC+3, Andrey Semashev =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:=
On Sunday 12 April 2015 05:09:= 29 Alexander Marinov wrote:
> I already sketched the details of this idea. You can read it here
> <https= ://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/RTs= s7Uyl
> zgQ>. Only someone needs to write a proposal and/or implement i= t as a demo
> in some open-source compiler (GCC or Clang).

No, I don't think your proposal is related to my idea. I'm not trying t= o make=20
a function constexpr, I'm trying to propagate compile-time nature of so= me of=20
its arguments to its body, which is executed in run time.

(offtopic: And I do think that inline and constexpr are different prope= rties=20
of the code, even though they are somewhat related on the implementatio= n side;=20
I do not think they should be mixed together in a single keyword.)

> =D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 12 =D0=B0=D0=BF=D1=80=D0=B8= =D0=BB 2015 =D0=B3., 13:33:17 UTC+3, Andrey Semashev =D0=BD=D0=B0=D0=BF=D0= =B8=D1=81=D0=B0:
> > Hi,
> >=20
> > I wonder if constexpr function arguments would be a useful ad= dition to the
> >=20
> > standard. Consider this part of std::atomic interface:
> >   template< typename T >
> >   void atomic<T>::store(T val, memory_order order)
> >   {
> >  =20
> >     switch (order)
> >     {
> >    =20
> >       // implementations with different memory= ordering guarantees
> >    =20
> >     }
> >  =20
> >   }
> >=20
> > The function itself is not constexpr because the implementati= on has a
> > runtime
> > side effect. However the memory order argument is always cons= tant in
> > normal
> > uses and the implementation could have had benefitted from kn= owing this
> > constant at compile time. The current standard does not offer= means for
> > that,
> > so you're out of luck if the compiler is not smart enough to = propagate
> > this
> > constexpr hint behind the scenes. For the most part with comp= ilers I have
> > experience with (gcc, icl, msvc) this only works when the com= piler is able
> > to
> > inline the function call.
> >=20
> > BTW, if anyone wonders if compiler intrinsics help here, no t= hey don't.
> > With
> >=20
> > the code similar to this:
> >   template< typename T >
> >   void atomic<T>::store(T val, memory_order order)
> >   {
> >  =20
> >     __atomic_store_n(&m_value, val, order);
> >  =20
> >   }
> >=20
> > gcc and icl simply fall back to memory_order_seq_cst regardle= ss of the
> > specified order if they cannot inline the function. This alwa= ys happens in
> > debug, for instance.
> >=20
> > What I'm thinking is if we could require some argument to be = constexpr and
> > pass that 'compile-timeness' hint to the function body, the i= mplementation
> >=20
> > could optimize better. For example:
> >   template< typename T >
> >   void atomic<T>::store(T val, constexpr memory_or= der order)
> >   {
> >  =20
> >     switch (order) // order is always constexpr
> >     {
> >    =20
> >       // implementations with different memory= ordering guarantees
> >    =20
> >     }
> >  =20
> >   }
> >=20
> > In this case the switch/case would always be optimized to a s= ingle case.
> > And
> > the intrinsic-based version would also work as intended. Also= , if we have
> > a
> > non-constexpr overload of this function we would also support= calling with
> > a
> > runtime value of the memory order (not that it would be of mu= ch use
> > though).
> >=20
> > I understand this would have consequences on the ABI because = constexpr
> > arguments essentiall require to duplicate the function body f= or each
> > constant
> > argument value. It's not a big problem though because we alre= ady do that
> > for
> > non-type template parameters.
> >=20
> > Opinions?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_224_724234951.1428844415939-- ------=_Part_223_1997393265.1428844415939-- .