From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) by sourceware.org (Postfix) with ESMTPS id F0B603858D35 for ; Tue, 22 Nov 2022 14:33:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F0B603858D35 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-x42b.google.com with SMTP id 140so14529565pfz.6 for ; Tue, 22 Nov 2022 06:33:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; 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=eU3XbVmKkt8AEPuODB16TIId5jTocVHt/juE3H+mPyg=; b=k93oSMtdAM/dwsOQcfOdgHUshXKwqThM/m5hJAdDsdvaROA5a0gl+Xhw7jz5rX7CnX uj69N5ukS1iSowmj+NI2TGE4aF/M+AuQzKm1a5PRjlJBEHMK2jlbj/0dFJ+TbnwWQcod Qr0IYRLJJGb9SfcuAjHuiklrQYZKL/d3fk0hX4c1I1ziJqocM2LzWyu9ScVOYmrFmanR rjil2P0fz+Jy2CDY7qVDLgiNKnrMD7UeN96vN7NiLmp4IRsSp0Pk9DFwkTlpjHQBtzDV O0YY7AB8eNALCFjLFoqqpmNaIgxgFQvNZ90pmNy4OOHe7R5mXa60rZ9IB5EJ18MA3GhZ iX2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=eU3XbVmKkt8AEPuODB16TIId5jTocVHt/juE3H+mPyg=; b=i40q6IMhMLVxXjbItnY0MUuUHHiCvQ+wYnNXQ09F5UeJUDRA573wvbwcJQUNxmK3E5 2VKBH6ruvVBF5jIT/CcrbHPT7xamawNlAXwQc0zDvP7i7NCliivmpKZDN2/hJR04udRu LztQaWpZvdqqC2/g5a2Sic+R9C4RCzU8CnTVx1P35x7RgAwekRk147KBP6MQfMf1sg9/ HP45DVE/KK99XOULJ4yepLT1SlMeVKq1jmiowmURXYLr1fdkpaVDHQDEttIOusct0EqW mhPBUpX7E7iTTnQyQnY9t168x94uvpk5yjzcMnVig82A2g8M3QhSQ05NaUU+HVzRwwHw 1oEw== X-Gm-Message-State: ANoB5pnI7+YS5e0npe8YQX+yoHWMqSkKnnkz+0k2K+hB1Amj5mCyz7y6 loeea5Rn3T/O/K1IKqKwbv8= X-Google-Smtp-Source: AA0mqf73B565ly0fGJciQnwi5onNRy1HjRjxJYkj1mbB912hCsRYjU2rSMMcjMcT+MuCJ5+XASTqjQ== X-Received: by 2002:a62:e412:0:b0:566:8395:6dfa with SMTP id r18-20020a62e412000000b0056683956dfamr8022062pfh.20.1669127592677; Tue, 22 Nov 2022 06:33:12 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::99f? ([2601:681:8600:13d0::99f]) by smtp.gmail.com with ESMTPSA id p2-20020a170902780200b00187022627d8sm12049364pll.62.2022.11.22.06.33.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Nov 2022 06:33:11 -0800 (PST) Message-ID: Date: Tue, 22 Nov 2022 07:33:10 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCH 1/8]middle-end: Recognize scalar reductions from bitfields and array_refs Content-Language: en-US To: Richard Biener , Richard Sandiford Cc: Tamar Christina , Tamar Christina via Gcc-patches , Richard Biener , nd References: From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.3 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 11/22/22 04:08, Richard Biener via Gcc-patches wrote: > On Tue, 22 Nov 2022, Richard Sandiford wrote: > >> Tamar Christina writes: >>>> -----Original Message----- >>>> From: Richard Biener >>>> Sent: Tuesday, November 22, 2022 10:59 AM >>>> To: Richard Sandiford >>>> Cc: Tamar Christina via Gcc-patches ; Tamar >>>> Christina ; Richard Biener >>>> ; nd >>>> Subject: Re: [PATCH 1/8]middle-end: Recognize scalar reductions from >>>> bitfields and array_refs >>>> >>>> On Tue, 22 Nov 2022, Richard Sandiford wrote: >>>> >>>>> Tamar Christina via Gcc-patches writes: >>>>>>> So it's not easily possible the within current infrastructure. But >>>>>>> it does look like ARM might eventually benefit from something like STV >>>> on x86? >>>>>> I'm not sure. The problem with trying to do this in RTL is that >>>>>> you'd have to be able to decide from two psuedos whether they come >>>>>> from extracts that are sequential. When coming in from a hard >>>>>> register that's easy yes. When coming in from a load, or any other >>>> operation that produces psuedos that becomes harder. >>>>> Yeah. >>>>> >>>>> Just in case anyone reading the above is tempted to implement STV for >>>>> AArch64: I think it would set a bad precedent if we had a >>>>> paste-&-adjust version of the x86 pass. AFAIK, the target >>>>> capabilities and constraints are mostly modelled correctly using >>>>> existing mechanisms, so I don't think there's anything particularly >>>>> target-specific about the process of forcing things to be on the general or >>>> SIMD/FP side. >>>>> So if we did have an STV-ish thing for AArch64, I think it should be a >>>>> target-independent pass that uses hooks and recog, even if the pass is >>>>> initially enabled for AArch64 only. >>>> Agreed - maybe some of the x86 code can be leveraged, but of course the >>>> cost modeling is the most difficult to get right - IIRC the x86 backend resorts >>>> to backend specific tuning flags rather than trying to get rtx_cost or insn_cost >>>> "correct" here. >>>> >>>>> (FWIW, on the patch itself, I tend to agree that this is really an SLP >>>>> optimisation. If the vectoriser fails to see the benefit, or if it >>>>> fails to handle more complex cases, then it would be good to try to >>>>> fix that.) >>>> Also agreed - but costing is hard ;) >>> I guess, I still disagree here but I've clearly been out-Richard. The problem is still >>> that this is just basic codegen. I still don't think it requires -O2 to be usable. >>> >>> So I guess the only correct implementation is to use an STV-like patch. But given >>> that this is already the second attempt, first RTL one was rejected by Richard, >>> second GIMPLE one was rejected by Richi I'd like to get an agreement on this STV >>> thing before I waste months more.. >> I don't think this in itself is a good motivation for STV. My comment >> above was more about the idea of STV for AArch64 in general (since it >> had been raised). >> >> Personally I still think the reduction should be generated in gimple. > I agree, and the proper place to generate the reduction is in SLP. Sorry to have sent things astray with my earlier ACK.  It looked reasonable to me. jeff