From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpout30.security-mail.net (smtpout30.security-mail.net [85.31.212.34]) by sourceware.org (Postfix) with ESMTPS id 147FA3858D35 for ; Tue, 26 Sep 2023 09:40:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 147FA3858D35 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=kalrayinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kalrayinc.com Received: from localhost (localhost [127.0.0.1]) by fx304.security-mail.net (Postfix) with ESMTP id 2AC889C72B9 for ; Tue, 26 Sep 2023 11:40:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kalrayinc.com; s=sec-sig-email; t=1695721224; bh=MtKHPGoms4YY+voIhvvA+ErB8OrUAhYgiNieeCP4Hjs=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=KrHETVPr3Aq8iSDkddidEebzsVnUpSxslbg6C8cG7UL0YMhWq6phD/4BOaVkQstju ABeGV538lv6oGfZqQjI4VLGzdQsd6Rs5NXn+O66KkOJheUDGR3KCWfR4dl6T58951T KwhznJT/K9gN3t2aGBF5g/MjfaA0XcI3jk6GixXA= Received: from fx304 (localhost [127.0.0.1]) by fx304.security-mail.net (Postfix) with ESMTP id F3A359C771B; Tue, 26 Sep 2023 11:40:23 +0200 (CEST) Received: from FRA01-MR2-obe.outbound.protection.outlook.com (mail-mr2fra01on0101.outbound.protection.outlook.com [104.47.25.101]) by fx304.security-mail.net (Postfix) with ESMTPS id 5C3299C751F; Tue, 26 Sep 2023 11:40:23 +0200 (CEST) Received: from MR1P264MB2482.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:33::22) by MR1P264MB1859.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:12::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6813.28; Tue, 26 Sep 2023 09:40:22 +0000 Received: from MR1P264MB2482.FRAP264.PROD.OUTLOOK.COM ([fe80::aeb6:2f26:45ff:5461]) by MR1P264MB2482.FRAP264.PROD.OUTLOOK.COM ([fe80::aeb6:2f26:45ff:5461%7]) with mapi id 15.20.6813.027; Tue, 26 Sep 2023 09:40:21 +0000 X-Virus-Scanned: E-securemail Secumail-id: ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aiGizlRuyLGowOC6JWmgr6e4DCtoe4TxyQfWXwgv+J4ZssvxW/HIWN+Zl3jPVuq7zMUmGdHO7mXAEWg5s9Ml/8JHmX75fMM537WWHbnFk4X8L6HmgJFABmWvqb1M93u1hEWSgSjIUvec/Yrm56eBHWibgWI3WCd9dvNXuYWFjizZ3LEeEahMNMmusTnUBoeTOQmi87HbGCC6zE97oKuMUAZIss5Dmq1tm1Hkzn5toqr90F+hjLY9Nux1iExXaxvhgrV+7SH05LJD1qhQetKtLD4oYOPLtVE+bU1c4uBd9/xSmW50N8ODuNER88/rfymS9yuLDXWpYGaMgELJ3JP6ag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+7KgrufH3jRMeso2zxS5vDuRZ6v6C1RbXLTJTa/Ta00=; b=LP4CchpTOaK44XsoaN8V2War1Fp1PmXmpswCl24A9B3JeSJHA4AkWEARSlidI/Hx6BUpK7uYQM3RB/v5D27Qw5zVyzCDXH0zE2poFADzDqhRtaBgameDLdlicxhku2P8fj7CjB1vnJvZUBsRtLl0EfPFPIa5P52Lw8xpnk18S54B3RD3/q7W6Xh6qGDL0oH8/W4hAYh1xyRwe+PeSRFpf3SreUM8SxTRdZIXoNCQ4fVNcTOmRJrnl+naD5srf8CYSzxn0qruXvKMXsx3vk99Ni/RF7qYqBLi4jOQq1RYuv/nNn5NMFrO9bNaIFlZgoKgNGKnOy2QlaacOb5n4VTkAQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=kalrayinc.com; dmarc=pass action=none header.from=kalrayinc.com; dkim=pass header.d=kalrayinc.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kalrayinc.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+7KgrufH3jRMeso2zxS5vDuRZ6v6C1RbXLTJTa/Ta00=; b=YmYiTDaXaVvUkGgokdZr41xblOo4yY9ZAaz6byoo3rlpnxkwLB/DfPsU/s+mblaiswUGYDy9wKVUemmNui/r1BcZo66mxJMfGw1MTYkESkr+RMR7SWBJTrHFTUtbDedF1kjxUsrg2PZiy3oQUyopmTEcfTHmwRyKGu+j4Xye1eU20bPvKV2UtUxVqjrF6AUNWOHr4x8cv+hDhlZqAnsTH4OWCg54Tv1hJhC+kpgyh9shomMjZ+R4Sul6KyCUL/C0kWCNxdSpEtlOF7HpKuMq3m2XhVoOKeGRl+ylxTragQ8KJevCj+QivaXNfbTldx6IIRKlxuybQVNlAuDkPpKzKw== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=kalrayinc.com; Date: Tue, 26 Sep 2023 11:40:20 +0200 From: Paul Iannetta To: Tamar Christina Cc: Richard Biener , Sylvain Noiry , gcc@gcc.gnu.org, sylvain.noiry@hotmail.fr Subject: Re: Complex numbers support: discussions summary Message-ID: <20230926094020.fol3nglpv5rwhfya@ws2202.lin.mbt.kalray.eu> References: <20230926085332.zyeemjgmkvrzvdli@ws2202.lin.mbt.kalray.eu> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20171215 X-ClientProxiedBy: LO4P265CA0024.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2ae::19) To MR1P264MB2482.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:33::22) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MR1P264MB2482:EE_|MR1P264MB1859:EE_ X-MS-Office365-Filtering-Correlation-Id: 98ea2218-1c7e-4612-68f7-08dbbe749a49 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Uh+8eiuDgqm7B5drryao0FlEKiTGbkhwqGW9dEY2CheSeVlUw0R/dN3VwWs/PLnRUrNWgMYJN33GFFyY0Qy2lexriE6M7tqaoAYGY0nqPCvaivGAiYCFSDJJzZUMYCCNOjtATYKRzUwwJ3+vVKIGfQHWsrab2tSV2krRoqddWhv4SgPR+psXyk5evaj9XOL24oSMte+gXK3A1UvjX8WykjosfQCo4HYtJ6TmoMXKER0unI57JxYDPhC4u95GlStbkfluD2mk++VwoXA9EmFghZQTNkk8OYUzLB7OXdWiO4+rQu/ux7u2YLg7MQCAFX94FezH/NHLTJw9WSru5Ss5yJDCXFQftY4q4ibx38xdF6qlmdEySmrL11KSZDIQf3GS4TbFePwdvV3PEwbl++eoWjj8+pL1Qr26wI5YJJcf5bwCyrpFOls3TK3ZSRNr+/E+8sTtEfJfSorEUm0r0XZ0qbwKy/7p+AMA2M1L4E7R361qHZvw1GIZ1oyHKbIGNulNXb4opCM85Qydz3uGeeQSRYELlKmi1fTe92l2IcqnZZ8= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MR1P264MB2482.FRAP264.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230031)(376002)(346002)(136003)(366004)(396003)(39850400004)(230922051799003)(186009)(451199024)(1800799009)(2906002)(86362001)(66899024)(5660300002)(6512007)(9686003)(6506007)(45080400002)(38100700002)(83380400001)(53546011)(478600001)(6486002)(8676002)(4326008)(8936002)(1076003)(41300700001)(26005)(66476007)(66556008)(66946007)(54906003)(6916009)(316002);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 96KcIH0BfaJwvx681oEtCE3DYIsyNfmEJCS9KelxZnL9jQA+h/iHXVKGH2nyCeBdmJvoRRDVtbMIv+jQl38LqKAwqVrYs3L0ey8fDhzVrbf8tjHJ4z3puDF+pBK1Tbz38FmNBMKppjxvO9Eu0HCh6VblmnZ66+wexB+vNw56ELESg9ES0J/YWVTBZ+DXMwewf7rbx5+ZRcTZ36ix2aJIjNsfnR9XDxC99lVYQO5U6miZeb90X/euLxcp4H74JF16QWdBhjXbou57QF22DZ7nxrrNrVCPNWbAmj6bgtGJncIF3bxMXOUkZQvX03Ve0k5dA+PB2ifRY+b6vAqShQOBnEZYpzZVylEgMjLt4yefrGkeJ+3fAoMFSnm+B18CSagaaWbd7k9RcluicZTptq8HjEgNp0rEARPVxKnSmDScWGD7bn36SKnKDjVda/DlBH4NvzStJJqEyT6WJpx3VcLLAPIX6aRutWzXTlBr6ocny2k0+YHZo0YmEQpiP/wDHBFiX5RUnfJsOppAcNpUPD6iEFgsoGwi3/xac23vzqKtQN1Sfw1DHsuwM1pBByepIRZL1q6MjY7Dl8CZq5GQAFEWj+1Fzcw2gXNKDpJ5IK0xRgzmmnIYGTI1/LKLOs1LlgXYaqoEOOSD+QWo3XRjRuXdLqRIejeH56hTbuQqZXr6Ug8n8JGA1fA886TLdl1CYegG1GhEHNnP1akETSxsB9qI4Od0XXLmPeQZMXGaBcsunGhLkKv6nemj1mUhpDRxoHaLLjh51v9Mi0SaSRVRqzTDy7bcHwl9kUPtWnE61sGbYGkNMarb8yB+/kqP/QFvMRi/+bgHPtPvAu7EPVZO9IM/UhbiDbzr9flTJy7eObCLmQyRm/H6uiVkPhtqJCfXxgPrjHaJh4afa9kb1Ay1a8NJTjHQgaSBs5+IFaKsut9vlV5zD05S9ZmaBAV5zGnov6gb Qt1QUwcU+7Tdp2aOvqyO5xHj3Tu5iAmjgZt2owesmoLJMPiMms3OA8pGPkT+qO7JQiRWU+dTafiKKBxflbUZJwlzQMZVYGIzNYrm6wlVGC+D9QTHXlvbhKvLshZbVN+9wDesKg6JePGl0nfsALsmf9mD7DTx7qI/HGhNxH0MAT3b2E58f3fwK2NgHiwEOxf96mieQEEZPpygPDbSCLjENHO3ZNtMPluz0SKW+lLGb/kVc47BlmXEo53ZU76SA0GD3ymoualhUGIl4JIIyPXc+SCgaDGdMP57qAobA/YqRtscYDTSYPbyT2CfdM5yyUHiW08mAV0YLyFHyqm39amQEvoEyiuFeTc7yDk8euwfnzxBrh391z5tOasHXfS8xuAU/ou31hHbcfO1ckNVJtWR0FBtRZAjXw8Yt4GiWbj6zXSXwCzv6lzlBqLOvE9SIT0wsXesN8o0V10xH7VzTtUe/py3wsDNwrHzA/Iw1zASCvJg5ZQMoZk1c1js1DdVUXecFtjD0SvUU8jaq0MHi1f5Jdo+B0rD7bxibsaKSVzkFiLV2TurUidd0WeY7ZxrSsQkHSbzKmN1sSxASa6yMAdNkL2EWYI9DvTa1hEWk+Um3KPt0ZlDoar22Z1xSeSNCTEx38TdtNaKXFyUuwtNA9bFXQ== X-OriginatorOrg: kalrayinc.com X-MS-Exchange-CrossTenant-Network-Message-Id: 98ea2218-1c7e-4612-68f7-08dbbe749a49 X-MS-Exchange-CrossTenant-AuthSource: MR1P264MB2482.FRAP264.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Sep 2023 09:40:21.8729 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 8931925d-7620-4a64-b7fe-20afd86363d3 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: TrMVuPwScbZnYeVTGDv2N8NOy/Mrv/RcoYbMPkAXnkElK0LqZT4QI7F4Ijx7PPjBDiH5KgcA85FwcIej+XJesg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MR1P264MB1859 X-ALTERMIMEV2_out: done X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, Sep 26, 2023 at 09:28:08AM +0000, Tamar Christina wrote: > > -----Original Message----- > > From: Gcc On Behalf > > Of Paul Iannetta via Gcc > > Sent: Tuesday, September 26, 2023 9:54 AM > > To: Richard Biener > > Cc: Sylvain Noiry ; gcc@gcc.gnu.org; > > sylvain.noiry@hotmail.fr > > Subject: Re: Complex numbers support: discussions summary > > > > On Tue, Sep 26, 2023 at 09:30:21AM +0200, Richard Biener via Gcc wrote: > > > On Mon, Sep 25, 2023 at 5:17 PM Sylvain Noiry via Gcc > > wrote: > > > > > > > > Hi, > > > > > > > > We had very interesting discussions during our presentation with > > > > Paul on the support of complex numbers in gcc at the Cauldron. > > > > > > > > Thank you all for your participation ! > > > > > > > > Here is a small summary from our viewpoint: > > > > > > > > - Replace CONCAT with a backend defined internal representation in > > > > RTL > > > > --> No particular problems > > > > > > > > - Allow backend to write patterns for operation on complex modes > > > > --> No particular problems > > > > > > > > - Conditional lowering depending on whether a pattern exists or not > > > > --> Concerns when the vectorization of split complex operations > > > > --> performs > > > > better > > > > than not vectorized unified complex operations > > > > > > > > - Centralize complex lowering in cplxlower > > > > --> No particular problems if it doesn't prevent IEEE compliance and > > > > optimizations (like const folding) > > > > > > > > - Vectorization of complex operations > > > > --> 2 representations (interleaved and separated real/imag): cannot > > > > impose one > > > > if some machines prefer the other > > > > --> Complex are composite modes, the vectorizer assumes that the > > > > --> inner > > > > mode is > > > > scalar to do some optimizations (which ones ?) > > > > --> Mixed split/unified complex operations cannot be vectorized > > > > --> easely Assuming that the inner representation of complex vectors > > > > --> is let to > > > > target > > > > backends, the vectorizer doesn't know it, which prevent some > > > > optimizations > > > > (which ones ?) > > > > > > > > - Explicit vectors of complex > > > > --> Cplxlower cannot lower it, and moving veclower before cplxlower > > > > --> is a > > > > bad > > > > idea as it prevents some optimizations > > > > --> Teaching cplxlower how to deal with vectors of complex seems to > > > > --> be a > > > > reasonable alternative > > > > --> Concerns about ABI or indexing if the internal representation is > > > > --> let > > > > to the > > > > backend and differs from the representation in memory > > > > > > > > - Impact of the current SLP pattern matching of complex operations > > > > --> Only with -ffast-math > > > > --> It can match user defined operations (not C99) that can be > > > > simplified with a > > > > complex instruction > > > > --> Dedicated opcode and real vector type choosen VS standard opcode > > > > --> and > > > > complex > > > > mode in our implementation > > > > --> Need to preserve SLP pattern matching as too many applications > > > > redefines > > > > complex and bypass C99 standard. > > > > --> So need to harmonize with our implementation > > > > > > > > - Support of the pure imaginary type (_Imaginary) > > > > --> Still not supported by gcc (and llvm), neither in our > > > > --> implementation Issues comes from the fact that an imaginary is > > > > --> not a complex with > > > > real part > > > > set to 0 > > > > --> The same issue with complex multiplication by a real (which is > > > > --> split > > > > in the > > > > frontend, and our implementation hasn't changed it yet) > > > > --> Idea: Add an attribute to the Tree complex type which specify > > > > --> pure > > > > real / pure > > > > imaginary / full complex ? > > > > > > > > - Fast pattern for IEEE compliant emulated operations > > > > --> Not enough time to discuss about it > > > > > > > > Don't hesitate to add something or bring more precision if you want. > > > > > > > > As I said at the end of the presentation, we have written a paper > > > > which explains our implementation in details. You can find it on the > > > > wiki page of the Cauldron > > > > > > (https://gcc.gnu.org/wiki/cauldron2023talks?action=AttachFile&do=view&tar > > get=Exposing+Complex+Numbers+to+Target+Back-ends+%28paper%29.pdf). > > > > > > Thanks for the detailed presentation at the Cauldron. > > > > > > My personal summary is that I'm less convinced delaying lowering is > > > the way to go. > > > > This is not only delayed lowering, if the SPN are there, there is no lowering at > > all. > > > > > I do think that if targets implement complex optabs we should use them > > > but eventually re-discovering complex operations from lowered form is > > > going to be more useful. > > > > I would not be opposed to rediscovering complex operations but I think that > > even though, rediscovering a + b, a - b is easy, a * b would still be doable, but > > even a / b will be hard. Even though, I doubt will see a hardware complex > > division but who knows. However, once lowered, re-associating a * b * c and > > more complex expressions is going to be hard. > > > > > That's because as you said, use of _Complex is limited and people > > > inventing their own representation. > > > > Yes, this would be a step back at first, but, proper support for _Complex would > > probably be an incentive for library writers to take them into account. > > > > > SLP vectorization can discover some ops already with the limiting > > > factor being that we don't specifically search for only complex > > > operations (plus we expose the result as vector operations, requiring > > > target support for the vector ops rather than [SD]Cmode operations). > > > > Our only concern with SLP is that it only works within loops. If we want to re- > > discover complex numbers we could either add a dedicated pass before the > > SLP vectorizer or rely on match.pd? > > SLP doesn't work in just loops. SLP works on scalar statements inside BBs starting > from sink (constructors, stores, reductions etc). > I think you're confusing Loop-Aware SLP and SLP (in GCC these are two different > Passes that share much common code. > Indeed, we conflated both. Thanks for pointing this out! Paul > Tamar > > > > > > > > There's the gimple-isel.cc or the widen-mul pass that perform > > > instruction selection which could be enhanced to discover scalar > > > [SD]Cmode operations. > > > > We'll have another look there. > > > > Thanks, > > Paul > > > > > > Richard. > > > > > > > Sylvain > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >