From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id 2C11D3858C20 for ; Tue, 11 Oct 2022 11:58:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2C11D3858C20 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-ej1-x62b.google.com with SMTP id k2so30867911ejr.2 for ; Tue, 11 Oct 2022 04:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/33R5a3RNB2kYqKkRbZiz2TwR5hTJuzHzoS+XKFOT6I=; b=k/k6KJq56ArsrJRnm+sntzd7X9BeJCEvyydEdMLjGT5O9sNl2r3k2IgSpMoCNuvu7M IgBBVLahUKUEBwLn102FV1AOToyrwS5ChFfJDkKVgUj4pV2yqY6f+Y+Ms8LOH+Wr/dKv skDDmNJOvOD89NNFU7ZJ4E2BCq1JHWXgjtR19cLG+sp7/QZu8ZN3kF/+eTwNIsP6ac/Y W/ODj/xft29b40hyFS+O4r0TpseRzRyIRGRA9WEE5cjpDRVHuvjytrMnWX5XqmlnFc4+ z5/3gNOhTEemNNS+7UItWNyYc6sEpSFM2DmKeaD4zzUeOxJw3lywigh518rk86nBlLF0 T/LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/33R5a3RNB2kYqKkRbZiz2TwR5hTJuzHzoS+XKFOT6I=; b=OeCjhMoVtNO5Qwy1ohcwW+FnOoZSX46KUQElY3Pf4KksopaJbhnbIKh+aTnNFc7er5 pTB6NoN79wxmfu92SOFW9rhrWrW3KHtYyMyduoXewRxQWvNE9rBdGKiDLo7wDmte5gG4 0RTk3GqWp057uaoJgyKdFE3CY+wTLLFK4Mm0yBxkRrUAHpYmgcTfOGU09Ybh8trLcvDF WDpqtGnjRpLuR8vCWzsHKucaK4xea6ODPXNEY4To2llTlVWQTr3GiW5b5xu9t+zbCYDi oKj06OeosJpSb2h33bu1b5j1nCz0k/c3Sh9xDvS7JQOMUOw6ECQL2WmKwWfZPWUravec PVAg== X-Gm-Message-State: ACrzQf2Cl3xCRIm73iddwWpozBkhf1W95RT0/BE49v/Zt08pkG9VVVgD dvNhghubwBrFU32SLa+yVd3CD39RRO0JNn6kBrvkGL6F X-Google-Smtp-Source: AMsMyM6aj2ienPmgzWmbCcXl2Sdgmvv6eu63zP4ivaRc+jC0jFIuPQWUnT+FAndmADtS+pxJ5BC7kww+keQDbp+kHgU= X-Received: by 2002:a17:906:5d0f:b0:78d:1bed:890f with SMTP id g15-20020a1709065d0f00b0078d1bed890fmr18826109ejt.594.1665489509505; Tue, 11 Oct 2022 04:58:29 -0700 (PDT) MIME-Version: 1.0 References: <00e7c525-cc0d-5144-d95c-573f75657e30@codesourcery.com> In-Reply-To: <00e7c525-cc0d-5144-d95c-573f75657e30@codesourcery.com> From: Richard Biener Date: Tue, 11 Oct 2022 13:58:17 +0200 Message-ID: Subject: Re: [committed 0/6] amdgcn: Add V32, V16, V8, V4, and V2 vectors To: Andrew Stubbs Cc: gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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 Tue, Oct 11, 2022 at 1:53 PM Andrew Stubbs wrote: > > On 11/10/2022 12:29, Richard Biener wrote: > > On Tue, Oct 11, 2022 at 1:03 PM Andrew Stubbs wrote: > >> > >> This patch series adds additional vector sizes for the amdgcn backend. > >> > >> The hardware supports any arbitrary vector length up to 64-lanes via > >> masking, but GCC cannot (yet) make full use of them due to middle-end > >> limitations. Adding smaller "virtual" vector sizes increases the > >> complexity of the backend a little, but opens up optimization > >> opportunities for the current middle-end implementation somewhat. In > >> particular, it enables many more cases of SLP optimization. > >> > >> The patchset gives aproximately 100 addtional test PASS and a few extra > >> FAIL. However, the failures are not new issues, but rather existing > >> problems that did not show up because the code did not previously > >> vectorize. Expanding the testcase to allow 64-lane vectors shows the > >> same problems there. > >> > >> I shall backport these patches to the OG12 branch shortly. > > > > I suppose until you change the related_vector_mode hook the PR107096 issue > > will not hit you but at least it's then latent ... > > How do you mean, change it? > > static opt_machine_mode > gcn_related_vector_mode (machine_mode vector_mode, > scalar_mode element_mode, poly_uint64 nunits) > { > int n = nunits.to_constant (); > > if (n == 0) > n = GET_MODE_NUNITS (vector_mode); > > return VnMODE (n, element_mode); > } > > > It returns what it's asked for, always matching the number of lanes (not > the bitsize), which is most likely the most natural for GCN. Yes, change it in any way no longer honoring that. Or discover the case (not sure if it actually exists) where the vectorizer itself tricks you into this by passing down nunits !=0 when vectorizing a loop (I _think_ that's only done for basic-block vectorization currently). Richard. > > Andrew