From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ubizjak@gmail.com>
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com
 [IPv6:2607:f8b0:4864:20::835])
 by sourceware.org (Postfix) with ESMTPS id D0AB93896804
 for <gcc-patches@gcc.gnu.org>; Thu, 12 Nov 2020 18:26:12 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D0AB93896804
Received: by mail-qt1-x835.google.com with SMTP id 7so4711120qtp.1
 for <gcc-patches@gcc.gnu.org>; Thu, 12 Nov 2020 10:26:12 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=+PJh1bT7+E7CAKpcvvUsJoK3sVWNczXtiZxjyETUwVM=;
 b=IWtkhsVD6S7pH9rhEvy9XxgcJyeBY+68JF5yyP/juoObBeABJQRHyn6IaU9BfUN67e
 HslWtPhblDsZMH2IjYY5c6PY0YDU+1aQmp5b0EbTqTog5zTWJzvQ2zII9Brqo/Fi7/9B
 m5r7x3+XuxwPb+SQNZQBuIyQ2xPr16n2sEiRDQIpZAEmH0c3rpii0mgFcMpVAk9q/ZRN
 ViI0d//pJ6OL7BMah8IAVJVnnWsGe8outp4ixyHUf9RWhlKzJxcEpYxCto7nhNUnoCxw
 6U+zRxKZm3W1xTlT1Y1c+iSfUdhyd61K2TSi2BhjrrWHoE57l+Mh0wewXOfLEsuNjG6J
 3sjw==
X-Gm-Message-State: AOAM532AvnI5Gg72HZj3I/ZrV5tBfUVModQiKDyXk+G/SboxgFbZ1P0X
 WeZ/DTHWKqdeTs9a1PjS2Ri8qQ8ZQV/ji/PhlfHS44jeKt5rTw==
X-Google-Smtp-Source: ABdhPJxCDZuoYzgKNhnf7ZOp5R1eWdfq2+c16rt9jXvTr/7v9WZzHTWMMi0LRf4bosgiQqSfj1JxUGsKLcHE1aATyfM=
X-Received: by 2002:ac8:7b92:: with SMTP id p18mr436733qtu.105.1605205572059; 
 Thu, 12 Nov 2020 10:26:12 -0800 (PST)
MIME-Version: 1.0
References: <CAFULd4ahGFL6eMMTsBVyWVNay7Z5O3cO5-dgr2haUSxGxTZxDQ@mail.gmail.com>
 <CAMZc-bzG_dovpusCa6TdM8brXpa5ceopo2MqfSC7=hKtW_NqjA@mail.gmail.com>
 <CAFULd4bEQFbF9qRpfFhZ+AfY6JVU8f5ZKHjty_TTjdr6yh5rFw@mail.gmail.com>
 <CAMZc-bzWNECExfOSiMpQS1ArqvYspO3Tp_JS04BHhsvYM01KUA@mail.gmail.com>
 <CAMZc-byFfm4HqPOTA5qgS32MLy6S4T4r7Gq+MxXezJsRxXpO1A@mail.gmail.com>
 <CAMZc-bwi5pKPhXou-xt56ug54ZT+XNaXiVarWnvTOFbRVsBv2Q@mail.gmail.com>
 <CAFiYyc1yCO1tzhYVw02850Rpte8P3NKMVF3o3RrZwOjwYb1O7A@mail.gmail.com>
 <CAFULd4YPGjewc6rV5NBfmq0Lrar4DG-HXhGLx1hgJheztOZkeg@mail.gmail.com>
In-Reply-To: <CAFULd4YPGjewc6rV5NBfmq0Lrar4DG-HXhGLx1hgJheztOZkeg@mail.gmail.com>
From: Uros Bizjak <ubizjak@gmail.com>
Date: Thu, 12 Nov 2020 19:26:00 +0100
Message-ID: <CAFULd4bad6vjVH2LeSMjG75i7KeHhCZOmjB0Oi0T7-9VizsiUg@mail.gmail.com>
Subject: Re: [PATCH] [PR target/97194] [AVX2] Support variable index vec_set.
To: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Cc: Hongtao Liu <crazylht@gmail.com>,
 Richard Biener <richard.guenther@gmail.com>, 
 Richard Sandiford <richard.sandiford@arm.com>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-4.4 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.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: gcc-patches@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Nov 2020 18:26:14 -0000

On Thu, Nov 12, 2020 at 6:51 PM Uros Bizjak <ubizjak@gmail.com> wrote:

> > > > Yes, removed 'code' and value_mode by checking VECTOR_MODE_P and use GET_MODE_INNER
> > > > for value_mode.  ".md expanders" shall support for integer constants index mode, but
> > > > I guess they shouldn't be expanded by IFN as this function is for variable index
> > > > insert only?  Anyway, the v3 patch used VOIDmode check...
> >
> > I'm not sure what best to do here, as said accepting "any" (integer) mode as
> > input is desirable (SImode, DImode but eventually also smaller modes).  How
> > that can be best achieved I don't know.
>
> I was expecting something similar to how extvM/extzvM operands are
> handled here. We have:
>
>     Operands 0 and 1 both have mode M.  Operands 2 and 3 have a
>     target-specific mode.
>
> Please note operands 2 and 3 having a "target-specific" mode, handled
> in optabs-query.c as:
>
>   machine_mode struct_mode = data->operand[struct_op].mode;
>   if (struct_mode == VOIDmode)
>     struct_mode = word_mode;
>   if (mode != struct_mode)
>     return false;
>
> > Why's not specifying any mode in the patter no good?  Just make sure you
> > appropriately extend/subreg it?  We can make sure it will be an integer
> > mode in the expander itself.
>
> IIRC, having known mode, expanders can use create_convert_operand_to,
> and the middle-end will do the above by itself. Also note that at
> least two targets specify SImode, so register operands are currently
> ineffective there.

On a related note, the pattern is currently expanded as (see
store_bit_field_1 in expmed.c):

      create_fixed_operand (&ops[0], op0);
      create_input_operand (&ops[1], value, innermode);
      create_integer_operand (&ops[2], pos);

I don't think calling create_integer_operand on register operand is
correct. The function comment says:

/* Make OP describe an input operand that has value INTVAL and that has
   no inherent mode.  This function should only be used for operands that
   are always expand-time constants.  The backend may request that INTVAL
   be copied into a different kind of rtx, but it must specify the mode
   of that rtx if so.  */

Uros.