220 39393 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:25:10 -0700 (PDT) Lines: 119 Approved: news@gmane.org Message-ID: 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_9646_85301419.1532507110259" X-Trace: blaine.gmane.org 1532506986 16260 195.159.176.226 (25 Jul 2018 08:23:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 25 Jul 2018 08:23:06 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDGKFT5YZADRBZ7H4DNAKGQEQKE22LI@isocpp.org Wed Jul 25 10:23:01 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f199.google.com ([209.85.213.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fiF4W-00047D-U9 for gclcip-std-proposals@m.gmane.org; Wed, 25 Jul 2018 10:23:01 +0200 Original-Received: by mail-yb0-f199.google.com with SMTP id b18-v6sf3462438ybq.9 for ; Wed, 25 Jul 2018 01:25:12 -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=3kfuDqhDppW4luJg6Brr2/ksYZO90RgUYBe3fsLcIwM=; b=QD9Yg2REjwSXgLuEsWd4l2pl/+LgkQ7Grk+5fqbj02VJi89jAyt3ymw3g7P6vNQu7z 9I5mwNSN4l/05KhmM21uKut8DuO5kpe4OTCAYsV+Wnks3F5THWlfs8n6mcFDLInnaV8x 2upem2E6oawManiaPPFKNrmqq903OQbYFrub8N7ZrtU4GDjS/fZ/DjQgHgat/3ax7ZrZ mh2UPMxmRJzb4MtIabz4JzihAYP9mEDheGCJ/026CT6VS38DLf1nGJRJyE1F6bMHmKgv Ar64FXedrczD34TqfL91vLQba4rizODR39Bcxcoyfe7BFev1G/lHyRp90QN4/F04vGYv z/lw== 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=3kfuDqhDppW4luJg6Brr2/ksYZO90RgUYBe3fsLcIwM=; b=W1pqU0RUlm6yyVzE1pdgcM+jh6QeE/y1SCnnYdYQrOi1uExPKhQL0BDFP+P24ZjJQ9 cjz+aMbX++gD5Q3nwH5Rrq1vIctElZGWYzQPLAFylQSMlOpqxZOGIKwiBM/rfoJZ4Pvy 9ZrjWm+c1RpnPUm2vbunkXC/wLEJekuvmfU0xc+N+7qJercg69p+X+dEwa3uVlZlWCJn ol+LlinEUwLcDzbhOZU7Cxoqn6flgpJkHoU+xFnxT2qFkuK8rTkCbp+7Z/ZHEU6hSsO8 jsSM+w7iqxWVBAmOYEbgfOyuEMNeZphTL9/2nWnFwPJsA79LXIL7g8X+q18zX/kKW1p+ MZ6w== 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=3kfuDqhDppW4luJg6Brr2/ksYZO90RgUYBe3fsLcIwM=; b=AlxCYij2BknQspgCNYiL47E35VfKvQHjDF7MvqzmLniQBFo3kxek5T3Z0L1s0tcknp qh66pG6s6alhEODaD5Mfns7kbi/Z2/XMvjhw+iZv6CXsvuEV69YVWgVcXyQifekEBhrL 7+dLSg/gqFFDQF/l9zXTQEa2rlS1lTE0gVy2vwQGQZI0tCYcurXi8KFOmh8jVkxNNHXD w+aExdwJZDYs06OipPTeM79a6Ho3LCRHlthQCqRR4v2EKjpHcflwA0QBMbbO2LyZV3cC 5cnBWz/SLYwA6OYMvz3kkekkDm4HQPHD4V2IgNho6EdC3ameepRVE7zIJ7tR5aduBjoZ hVvw== X-Gm-Message-State: AOUpUlH4nTnkXuJt0xC+/nvUWrZUPorQKT0RWheeGzuws9sxmLegsifp bP7Wc9a3sRyDe6hSIKVyICaomQ== X-Google-Smtp-Source: AAOMgpdIS0MHl+1bkfj7rD5YV/I4Igi5MSrQUx1OKbPCZyx1lMUR1HLJ8hPj3Xh3VZOqqzKxdV/xVw== X-Received: by 2002:a81:94c5:: with SMTP id l188-v6mr4737691ywg.237.1532507111641; Wed, 25 Jul 2018 01:25:11 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a0d:dc43:: with SMTP id f64-v6ls2101939ywe.29.gmail; Wed, 25 Jul 2018 01:25:10 -0700 (PDT) X-Received: by 2002:a0d:de01:: with SMTP id h1-v6mr373630ywe.3.1532507110774; Wed, 25 Jul 2018 01:25:10 -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:39393 Archived-At: ------=_Part_9646_85301419.1532507110259 Content-Type: multipart/alternative; boundary="----=_Part_9647_1588443923.1532507110259" ------=_Part_9647_1588443923.1532507110259 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, 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 two 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/c0b3f7b6-e611-45a9-8f54-e49b7e840b6b%40isocpp.org. ------=_Part_9647_1588443923.1532507110259 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, exe= cuting 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 va= riants. On those architectures - which represent a good fraction of all CPU= s likely to be in use in five years time - I found between zero and two CPU= cycle overhead, assuming all warm cache. The out of order cores were almos= t always zero overhead as the code after the return from function is specul= atively executed.
=C2=A0

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 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/c0b3f7b6-e611-45a9-8f54-e49b7e840b6b= %40isocpp.org.
------=_Part_9647_1588443923.1532507110259-- ------=_Part_9646_85301419.1532507110259-- .