From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) by sourceware.org (Postfix) with ESMTPS id 8DBB73858D20 for ; Thu, 31 Aug 2023 06:41:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8DBB73858D20 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-lj1-x233.google.com with SMTP id 38308e7fff4ca-2bc63e0d8cdso9023161fa.2 for ; Wed, 30 Aug 2023 23:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693464080; x=1694068880; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=fym4pd237aTwgf7In7mCeV/vG9tsOk15IbHSSc9mTDw=; b=i7D5grYtW7NnXeYd+Q64N+ejJ1NxFE+qbuX33A7W5egR7/4NZtmiML9sjXKCuw8dn6 75iG4MEWidOqB2oSyAMrusEDfEnbdDVwkFTg5IxJo2YSJjdCMP+kT3bd+T1ME+UxRdu/ /VWYR/nzme6ziWgV3UX/Du7FvQgVlFHitVeaS7OksRYHrMP7K4arhNSkaORFK8W8111y actcvzS4repSM18q1WNsBWgvx4P95EmnrPL0i0HwEkSFCdcf+plspsczyFGp70KMVKs9 ki3lD6KMVMNjhYi3Ij90f8OgRqmFBayVJK6cJVjuDwNJDThYHyoj12KyyL+PeKCYTiCl 35Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693464080; x=1694068880; h=content-transfer-encoding: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=fym4pd237aTwgf7In7mCeV/vG9tsOk15IbHSSc9mTDw=; b=F3hy6YD3biRuVEOL1qWGe5Np9rTSIWvGHYvsruBbElP7DvZULYyFMZ2uwrSZeDYoRU GoMPlCAZSGtqJfU+UOTUvVSUufw4bMGaXrLnkIGpSpR0csBZdDmoM8eN+FS5obRk2Erw 00Y0MltHwZEH/SiwRyXp1xUqfT69ENz9eER9WbXSvGYskL1gwXZfLWUBRmcWyU5JJx1L XqeBrdF+PDXCx3lVBSkEPBZZ+bUuVqCf12G13EsyrjpCT97B9FGJ1eJH3z91R+arAjjk Ucz6nIPn8920lRNoR172ayQfPWWTWRi9Gd023HhFEtIasf013c2P1byDf6+ocZbQxTV6 mcFA== X-Gm-Message-State: AOJu0YzHrNhP+BXyKIzl44mTRDy10OpRCHjOOgN5PtMYRZFdt83PRp4y qVuWWH0y8We1esPUzA9E5SwjDj0sJvmzSAvrdws= X-Google-Smtp-Source: AGHT+IGtgEpnTc1e7G6zjoYQj12uSxUVrt2TwVgdJ43rFbfQexyP0xxQpW91dWZVWrKla113O/oSovD6lQMWORZlhJk= X-Received: by 2002:a2e:9bd6:0:b0:2bd:b99:ab7e with SMTP id w22-20020a2e9bd6000000b002bd0b99ab7emr3915589ljj.42.1693464079688; Wed, 30 Aug 2023 23:41:19 -0700 (PDT) MIME-Version: 1.0 References: <73b53052-c3a4-4028-2836-ade419431eda@arm.com> <4eda2924-2fe1-63ed-d6c5-2bdea8fd34d3@arm.com> <26e25940-8ae8-148c-3d1e-1e68d7758648@arm.com> In-Reply-To: <26e25940-8ae8-148c-3d1e-1e68d7758648@arm.com> From: Richard Biener Date: Thu, 31 Aug 2023 08:39:37 +0200 Message-ID: Subject: Re: [PATCH 6/8] vect: Add vector_mode paramater to simd_clone_usable To: "Andre Vieira (lists)" Cc: gcc-patches@gcc.gnu.org, Richard Sandiford Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.6 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 Wed, Aug 30, 2023 at 5:02=E2=80=AFPM Andre Vieira (lists) wrote: > > > > On 30/08/2023 14:01, Richard Biener wrote: > > On Wed, Aug 30, 2023 at 11:15=E2=80=AFAM Andre Vieira (lists) via Gcc-p= atches > > wrote: > >> > >> This patch adds a machine_mode parameter to the TARGET_SIMD_CLONE_USAB= LE > >> hook to enable rejecting SVE modes when the target architecture does n= ot > >> support SVE. > > > > How does the graph node of the SIMD clone lack this information? That = is, it > > should have information on the types (and thus modes) for all formal ar= guments > > and return values already, no? At least the target would know how to > > instantiate > > it if it's not readily available at the point of use. > > > > Yes it does, but that's the modes the simd clone itself uses, it does > not know what vector_mode we are currently vectorizing for. Which is > exactly why we need the vinfo's vector_mode to make sure the simd clone > and its types are compatible with the vector mode. > > In practice, to make sure that a SVE simd clones are only used in loops > being vectorized for SVE modes. Having said that... I just realized that > the simdlen check already takes care of that currently... > > by simdlen check I mean the one that writes off simdclones that match: > if (!constant_multiple_p (vf, n->simdclone->simdlen, &num_calls) > > However, when using -msve-vector-bits this will become an issue, as the > VF will be constant and we will match NEON simdclones. This requires > some further attention though given that we now also reject the use of > SVE simdclones when using -msve-vector-bits, and I'm not entirely sure > we should... Hmm, but vectorizable_simdclone should check for compatible types here and if they are compatible why should we reject them? Are -msve-vector-bit= s "SVE" modes different from "NEON" modes? I suppose not, because otherwise the type compatibility check would say incompatible. > I'm going on holidays for 2 weeks now though, so I'll have a look at > that scenario when I get back. Same with other feedback, didn't expect > feedback this quickly ;) Thank you!! > > Kind regards, > Andre >