From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <richard.guenther@gmail.com>
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c])
	by sourceware.org (Postfix) with ESMTPS id 08D0C3858D28
	for <gcc-patches@gcc.gnu.org>; Thu, 29 Sep 2022 07:52:49 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 08D0C3858D28
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-x62c.google.com with SMTP id a26so1092080ejc.4
        for <gcc-patches@gcc.gnu.org>; Thu, 29 Sep 2022 00:52:48 -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;
        bh=gSGZnhkDHV0ECcKX1bsgWNDsAa9RJIkCR3J7iRYLOlw=;
        b=HViFoXfIwdM3c0qISt1NGklGyaKnU+2TMok9kal3KMwk3hQAa6IJIxe97EpxVphdlr
         O7JdSQ/cpM/lUMP4e6D9FAc4NnhJ5wluUOgeL2SxqpfzP6YFzLHiBI9XuQmdvdE72L6C
         gdTXUMXfLgmmit3W7cQMZ9UXe2zql23LN1s0KJ9Qj2bif4c3Kl38cUR7D8m0oYLZ/Fbe
         KydGOtojEFNh4sUOa+7oP1uVCgbExcgMz+kGlu7bnZxOjSZGHy7mQYa9iEKG7sEPffzR
         KlTvn7NyPKRGsbgUsr2OBFzfCvQ2n2u0eXM/cG7EZhswA7eTUWAKnNLpsYvYdha/N8dc
         JwYg==
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;
        bh=gSGZnhkDHV0ECcKX1bsgWNDsAa9RJIkCR3J7iRYLOlw=;
        b=ht053UycuA9PiHFm9v4Wi7xvYmDihKkvwsvCUt8WAJsQ5p+0h36coxD/h6NZvfBj/T
         iGxKxUZTeD8LabjRgAd5EA/facdeOzfuAhb5CpUVBGcPz8DkHMh93Vuu/FP6+r7BrdST
         rUF1sfMF8bJmO3QtW9zD207SmIr1Pf2XRSeVrI6EhoHBlJ1LHg/P959AE+PyMfX32g9n
         LIabiIIJYD35g8olbSGkF/Hcr9Q78yFLjCt9QmHqtB5WKixTVktBfdwta6uZoVkD9JHg
         Ohe4BRHuCGSw+pvgB+KXE03sCpkhYngZpl/B3/YaP262tDA2TxMPjdDjqGah64wMu8YW
         h7Qg==
X-Gm-Message-State: ACrzQf1FJYDO7TyTgIHtm4iUmeOiTz49E8ZduX5jHVEQBkvKhjWyUIIT
	M5r+ZIpguikMQNHVk+4Yy4AVt9GOfUWKjuH5Npc=
X-Google-Smtp-Source: AMsMyM6PNtLphpK4mL4nlv/x8UrGRq59UOk0+jrrDgw7WkXzijqSpLxaWesXv2XHDTb4d65nJHO/W9AKKgwlaPAHeuE=
X-Received: by 2002:a17:907:7632:b0:76f:f6e7:36cf with SMTP id
 jy18-20020a170907763200b0076ff6e736cfmr1658849ejc.442.1664437967866; Thu, 29
 Sep 2022 00:52:47 -0700 (PDT)
MIME-Version: 1.0
References: <87180de9-d0d4-b92f-405f-100aca3d5cf8@codesourcery.com>
In-Reply-To: <87180de9-d0d4-b92f-405f-100aca3d5cf8@codesourcery.com>
From: Richard Biener <richard.guenther@gmail.com>
Date: Thu, 29 Sep 2022 09:52:34 +0200
Message-ID: <CAFiYyc0YG=kcSHkG7E4eV8HC0A8SRiDh6ScQndDd6By7ExoE+g@mail.gmail.com>
Subject: Re: [PATCH] vect: while_ult for integer mask
To: Andrew Stubbs <ams@codesourcery.com>, Richard Sandiford <richard.sandiford@arm.com>
Cc: "gcc-patches@gcc.gnu.org" <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: <gcc-patches.gcc.gnu.org>

On Wed, Sep 28, 2022 at 5:06 PM Andrew Stubbs <ams@codesourcery.com> wrote:
>
> This patch is a prerequisite for some amdgcn patches I'm working on to
> support shorter vector lengths (having fixed 64 lanes tends to miss
> optimizations, and masking is not supported everywhere yet).
>
> The problem is that, unlike AArch64, I'm not using different mask modes
> for different sized vectors, so all loops end up using the while_ultsidi
> pattern, regardless of vector length.  In theory I could use SImode for
> V32, HImode for V16, etc., but there's no mode to fit V4 or V2 so
> something else is needed.  Moving to using vector masks in the backend
> is not a natural fit for GCN, and would be a huge task in any case.
>
> This patch adds an additional length operand so that we can distinguish
> the different uses in the back end and don't end up with more lanes
> enabled than there ought to be.
>
> I've made the extra operand conditional on the mode so that I don't have
> to modify the AArch64 backend; that uses while_<cond> family of
> operators in a lot of places and uses iterators, so it would end up
> touching a lot of code just to add an inactive operand, plus I don't
> have a way to test it properly.  I've confirmed that AArch64 builds and
> expands while_ult correctly in a simple example.
>
> OK for mainline?

Hmm, but you could introduce BI4mode and BI2mode for V4 and V2, no?
Not sure if it is possible to have two partial integer modes and use those.

Richard.

>
> Thanks
>
> Andrew