220 39394 <9ae9bd6a-a5cd-4aa7-b603-24f8964cbe2e@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Niall Douglas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Alternative proposal for mapping P0709 Deterministic Exceptions into C Date: Wed, 25 Jul 2018 01:26:51 -0700 (PDT) Lines: 120 Approved: news@gmane.org Message-ID: <9ae9bd6a-a5cd-4aa7-b603-24f8964cbe2e@isocpp.org> References: <6a65c934-5d2a-4e75-b88d-9eaaee338bd3@isocpp.org> <87240a3d-623f-4f7f-8e7c-fa8c9482fa72@isocpp.org> <5a449c86-b0f4-4b07-b5d6-21b7adbfd63b@isocpp.org> <4e6835ac-6975-4c89-81c4-fc038d004cb7@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_9409_346432197.1532507211862" X-Trace: blaine.gmane.org 1532507089 23321 195.159.176.226 (25 Jul 2018 08:24:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 25 Jul 2018 08:24:49 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDGKFT5YZADRBTHI4DNAKGQEINM7GEY@isocpp.org Wed Jul 25 10:24:45 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f198.google.com ([209.85.161.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fiF6A-0005uX-AJ for gclcip-std-proposals@m.gmane.org; Wed, 25 Jul 2018 10:24:42 +0200 Original-Received: by mail-yw0-f198.google.com with SMTP id r144-v6sf3835818ywg.9 for ; Wed, 25 Jul 2018 01:26:53 -0700 (PDT) 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 :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=3DXkoU1mwGlCavgipkZ9lNLTaRfruiS76d/IPIP+Pt0=; b=jswYqEwpDW8PVx7h6Mwnbobm+oiD0vwu7LG+8ei5nK1t+eI8fS9xHpvhlzA4HIMmpG uj7guOuST3Bv/51kWLXH0L2XyzY+Q67qVb0dlzmC0d2GkCS0TICBfW2UJYpYkdb7WM/w JJU2pZPL+A9Mq/dFn+W6YXLVDqJRJ8ZfX6evV2jYQ3sDhy2+dtjCPuGwjAqX1Tmj3m/L FYOW/fjpsB8XH/ePn9aGSrgM3dmDT0m8qc1q2uRgXpVhGju9K9JDe8swoNIdaDJxhcLj 6GaChXLpS6SIX2ysb37BHI2QKyELTlHbo1forrn034wOq8xP+KiJRDAUWFVTq+NA7oQu OZhA== 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 :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=3DXkoU1mwGlCavgipkZ9lNLTaRfruiS76d/IPIP+Pt0=; b=cUJZ9WK2+JwpzspXLx6hUYbatw9sgOAzbqYAM1hHLwQ16DZOLs2grpyywRiMvmo2Js mTEZAMuc0KcOFkHi+ktj8yUBC7FSYbSa3G3ckwZidziVNMGzaFxjpQLzwaTAONm51xDp JxJEiWn+rLbqmH8yTNo5kbtmVlarFO9AH2NjTJBC2WscHnIiInrF/Nom1s7YEBnxVJP1 vHXu6ZRabDyq29/bzl9yV+boS3xfYuDB28SQ1jKsY7Ml3gZdqqeCmGa8UAvX3yHlXrmf AJBE8oBTp55IumZRpRUNOJPoFblul59mIo/Iv0DUT+Izjp+kczFLv0F7OL5XbOmyQ1w0 zdRw== 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=3DXkoU1mwGlCavgipkZ9lNLTaRfruiS76d/IPIP+Pt0=; b=DG08FnAFLfNCu0GWXh6vYMF+RJfFoQbK/0/XaUJQPEH05R2w9K85ugsrjWPtxlaX8S GHSNKvHg6CzAKbyk2wCeUWJ+QJPyTPqo2SAkKodFmMpFAQiY6Xsb6WUpEYvtoD678goS u8FgjkcfEV3sb7nJnGycNelRgYRaOOayTxeQ7svRmU3KQ1QfWXyazRPp3Crw5xs9BZIv voOw2OOHO3XqF2/T/eaFoheHsVfP7j9Dfkxb9sYngAVt4tGIalHJxmJOjblAlBLzZsDo HTjbARpIwUUrmPB5/P8ljr0LKhO9HHZ02/1Y2QgRAEPgtoj7uhAuYHP729GDvFUmSsbu Patg== X-Gm-Message-State: AOUpUlHInrKqsX5lOveymNp2trKi7/WC2fEL64kXmmnxJZ1KcEkPvpS4 XyWl2JZCNiA3BSADYAMDr3LUWQ== X-Google-Smtp-Source: AAOMgpcS+cSferEMSHRXBUH/vYkig3dSMgSK1ZfbaFe2zdl6kVSCftc8xZafjHmHCUYVPBpDYCdZyw== X-Received: by 2002:a81:25d5:: with SMTP id l204-v6mr5536080ywl.216.1532507213207; Wed, 25 Jul 2018 01:26:53 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:8008:: with SMTP id m8-v6ls3266770ybk.11.gmail; Wed, 25 Jul 2018 01:26:52 -0700 (PDT) X-Received: by 2002:a25:c5d2:: with SMTP id v201-v6mr342446ybe.4.1532507212331; Wed, 25 Jul 2018 01:26:52 -0700 (PDT) In-Reply-To: X-Original-Sender: nialldouglas14@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:39394 Archived-At: ------=_Part_9409_346432197.1532507211862 Content-Type: multipart/alternative; boundary="----=_Part_9410_604003079.1532507211863" ------=_Part_9410_604003079.1532507211863 Content-Type: text/plain; charset="UTF-8" On Tuesday, July 24, 2018 at 2:16:56 PM UTC+1, David Brown wrote: > > On 24/07/18 12:38, Niall Douglas wrote: > > The pipeline bubbles you refer to only occur when testing more than > > one CPU flag at a time. One of the main reasons for choosing the > > carry bit as return discriminant is because there are instructions > > for testing just the carry bit alone on all such architectures. Thus > > such partial flags stalls will never occur in this specific use > > case. > > > > I am reluctant to be so confident about the effects here - I really > don't think you can generalise and say these stalls will never occur. Remember we only care about the specific case of where an extern, non-inlined function returns. On every architecture, that would involve causing the carry flag to be set or be cleared (or equivalent in TLS), executing a return from subroutine, and in the caller doing a branch if carry set or clear. When researching all this some years ago now, I studied x64, ARM and AArch64, both in order and out of order variants. On those architectures - which represent a good fraction of all CPUs likely to be in use in five years time - I found between zero and three CPU cycle overhead, assuming all warm cache. The out of order cores were almost always zero overhead as the code after the return from function is speculatively executed. > > On a related point, many compilers do not track the state of flags > across instruction pattern boundaries - /any/ use of a carry flag like > this would involve significant engineering effort. > > Again, we only care about calls to non-inlined extern functions. In all other cases, any use of the carry flag will be optimised out. So in fact the proposed mechanism is purely about calling convention of extern functions only, and should require very little work on the compiler because for calls of extern functions, no optimisation is possible in its calling convention anyway. Niall -- 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/9ae9bd6a-a5cd-4aa7-b603-24f8964cbe2e%40isocpp.org. ------=_Part_9410_604003079.1532507211863 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tuesday, July 24, 2018 at 2:16:56 PM UTC+1, David Brown= wrote:
On 24/07/18 12:38, Nial= l Douglas wrote:
> The pipeline bubbles you refer to only occur when testing more tha= n
> one CPU flag at a time. One of the main reasons for choosing the
> carry bit as return discriminant is because there are instructions
> for testing just the carry bit alone on all such architectures. Th= us
> such partial flags stalls will never occur in this specific use
> case.
>=20

I am reluctant to be so confident about the effects here - I really
don't think you can generalise and say these stalls will never occu= r.

Remember we only care about the specifi= c case of where an extern, non-inlined function returns. On every architect= ure, that would involve causing the carry flag to be set or be cleared (or = equivalent in TLS), executing a return from subroutine, and in the caller d= oing a branch if carry set or clear.

When research= ing all this some years ago now, I studied x64, ARM and AArch64, both in or= der and out of order variants. On those architectures - which represent a g= ood fraction of all CPUs likely to be in use in five years time - I found b= etween zero and three CPU cycle overhead, assuming all warm cache. The out = of order cores were almost always zero overhead as the code after the retur= n from function is speculatively executed.
=C2=A0

On a related point, many compilers d= o not track the state of flags
across instruction pattern boundaries - /any/ use of a carry flag like
this would involve significant engineering effort.

Again, we only care about calls to non-inlined ex= tern functions. In all other cases, any use of the carry flag will be optim= ised out. So in fact the proposed mechanism is purely about calling convent= ion of extern functions only, and should require very little work on the co= mpiler because for calls of extern functions, no optimisation is possible i= n its calling convention anyway.

Niall=C2=A0
=

--
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/9ae9bd6a-a5cd-4aa7-b603-24f8964cbe2e= %40isocpp.org.
------=_Part_9410_604003079.1532507211863-- ------=_Part_9409_346432197.1532507211862-- .