From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) by sourceware.org (Postfix) with ESMTPS id 07E6E3858D20 for ; Tue, 29 Aug 2023 12:34:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 07E6E3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pf1-x431.google.com with SMTP id d2e1a72fcca58-68a3e271491so2742283b3a.0 for ; Tue, 29 Aug 2023 05:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693312451; x=1693917251; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=OcPBIsvlZvItSQBE9R0mYS3XOWbEsh8UXvHccfrDP8k=; b=Evkx7wjHy6Nl8s20uPXBMssUd0Dc/ubAz5RXDNRTzI5hzWrWRTSRfx5bSAfYslkbVp SvPpsJPHE8Z7QoCE96R2nmJwRo/pdgPvQiOv85OXs26tOeznjUgAd41//Txx35hFiPE8 mD5lcSmPLjIMgTHdbzr0uIZgyOMGq/vQewAnMNqpKgpLW1vWqlarT35dEmIpvUubiw4O fg5qZqnjkMadXLquR60y+gQSC3dmFcJTJwT5wODZIm4LqPum+OywyOigv5WXhCOOP1fe fLfkLwxj4C4MdkfxbhMkUfhk/8qH2ztpa3Fqjk9NvPA2mIgJFEiHKJF5rSTyVGMPf8BC 96aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693312451; x=1693917251; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=OcPBIsvlZvItSQBE9R0mYS3XOWbEsh8UXvHccfrDP8k=; b=SYGA1ZS70O+7iXIWcave5sOcphsuLwQ8UZjDTJ5/PMgZbXK1ORVI+vCngsxfL3Ghlf 95vV8tjb8J6Lyyk59fI8E1ddvEJshP9p9+bC8pkUV0osKNC2B8TOOoIiZIPD6mYhUUXN dK6J6xUwXdSK+JC9UmokEOd3AF62PU3bpsV/YhgM4r5eZlZqxJO/zHk/Pn2dv0vg2XzF Ojea4kGh90xpdoWF5ZNnAdkL9kMRmydvhDSO7Gi+4svcEQN7I/qZNZ33j4PPzPyu60xL fCsNfUwVVMwSOpnc80vc5Xvx/qaCzUbqg/SP+n0vnzfz4XoQNu8wDnZvVlO4txkOEy6F seVg== X-Gm-Message-State: AOJu0YyCpN2G7FENtRiEncMm3yTpob/N15vim26r5pxc5e6lSzp/9nGt 5/oPPRkKCUP7hK6AYR871Xs= X-Google-Smtp-Source: AGHT+IG4PNZnEWjmEP/YWStnRI5xs56oPry5ypMvm3RrmnhiCjgch3PrIt12P4uQxWuNrbPtnvxjUw== X-Received: by 2002:a05:6a00:1a13:b0:68a:49bc:9be3 with SMTP id g19-20020a056a001a1300b0068a49bc9be3mr24764587pfv.29.1693312450660; Tue, 29 Aug 2023 05:34:10 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id fk22-20020a056a003a9600b006889511ab14sm8422434pfb.37.2023.08.29.05.34.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Aug 2023 05:34:10 -0700 (PDT) Message-ID: <8b1e9410-1a81-801a-6678-e3deb017e51c@gmail.com> Date: Tue, 29 Aug 2023 06:34:08 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH] [tree-optimization/110279] swap operands in reassoc to reduce cross backedge FMA Content-Language: en-US To: Richard Biener , Martin Jambor Cc: Di Zhao OS , "gcc-patches@gcc.gnu.org" References: <4c3c9a1c-e182-30a9-342d-525adfb8cffd@gmail.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,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 8/29/23 01:41, Richard Biener wrote: >>> >>> _1 = a * b; >>> _2 = .FMA (c, d, _1); >>> acc_1 = acc_0 + _2; > > How can we execute the multiply and the FMA in parallel? They > depend on each other. Or is it the uarch can handle dependence > on the add operand but only when it is with a multiplication and > not a FMA in some better ways? (I'd doubt so much complexity) I've worked on an architecture that could almost do that. The ops didn't run in parallel, but instead serially as "chained" FP ops. Essentially in cases where you could chain them they become a single instruction. These were fully piped, thus issuing every cycle. Latency was 1c faster than if you'd issued the ops as distinct instructions. More importantly, by combining the two FP ops into a single instruction you could issue more FP ops/cycle which significantly helps many FP codes. It's safe to assume this required notable additional FP hardware, but it's something we already had in the design for other purposes. I keep hoping that architecture becomes public. There were some other really interesting features in the design that could be incorporated into other designs with minimal hardware cost. > > Can you explain in more detail how the uarch executes one vs. the > other case? Probably can't say more than I already have. Anyway, given the architecture in question is still private and no longer something I have to champion, if you want to move forward with with the patch, I won't object. jeff