From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=Dffx=3R=vrull.eu=philipp.tomsich@sourceware.org>
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a])
	by sourceware.org (Postfix) with ESMTPS id 6F26B38FF721
	for <gcc-patches@gcc.gnu.org>; Thu, 17 Nov 2022 16:46:13 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6F26B38FF721
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=vrull.eu
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=vrull.eu
Received: by mail-lf1-x12a.google.com with SMTP id be13so3739689lfb.4
        for <gcc-patches@gcc.gnu.org>; Thu, 17 Nov 2022 08:46:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=vrull.eu; s=google;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=tEoemy72eHgRic2Q3rVbnrjWf/l33yEwLl6dqaX9uuY=;
        b=WI/kFjHO+vVk607W+lyi/R/KLxoYOq4D3prxBPWxvlmZBZ5vMkr6f3s5b9mmgkfIu7
         Z79AW+Ojz9YP+hBz5gtXrXmLN0+qYgJM5352cmUYTq+Ep+GwNX867RsrbIwlWcxOuMW8
         qlIh5YX0g/5Za/ZTD1gh2U1vqwqrcwER9MqYJQLfLoTT1FkyFLk63oqzPl1F8/L1NnUA
         jBGbzfSbOnWfGSEXZp0bSLc8kLqzrQsuSIKNC3rsKpNmycnJ11d7L49ewoWbCGKsJzAJ
         3G5ZhAWJzrLvC8Ythv6tZ8WXMTustOT86m490bxFjXoyFJ6E4+E97DOnUiVvkCuq3evD
         EZIw==
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=tEoemy72eHgRic2Q3rVbnrjWf/l33yEwLl6dqaX9uuY=;
        b=73NywkuWh1qQ0l+Zuc1E21jaMt42ljLw2u3PgICOAFkT+D8GNo9DzIS7jPaKnZSsbJ
         uB1huinJs/IYfFIao52/4/UI8XjtE3I3kySppHGZAyUq4HMW8iC6V6gGyEqSJg/Ul9wl
         JnikmsP7T1M23+kw1iKxh1P7sWR1MhBAUs1J8Ab16n51sarrVxcNxKUeIuxYokAfLkiQ
         ZRQRBX8yoCle4YrmbsK8lPtPUZUgHbbmb/nKeAFgQ64M0OCkHFlfa9XVbB5JjUg1fjq0
         xIT6GbvEeYqd2id+zkjR9T+CTO6UOyj+jJlY/8EFxvssuH2MpWeUY+ntoHUI1nO9bN9j
         Oqag==
X-Gm-Message-State: ANoB5pl2azxl1fwVodMkLwzl+ZH26XGfHUYXbOpCqKOXkQZFMA4LcgXN
	hw8UALgT8zU4r2d+Tp/kAGUE8KNZKi71BrxocotoUQ==
X-Google-Smtp-Source: AA0mqf5XEtgV4qtC9XNmw5FHEPym2rU3QUZ5lW5qb7c/5gkgl+i8VyMhxWDehXKLW4dyVif0uCBnllZtvgKpj/jSDs8=
X-Received: by 2002:ac2:4d83:0:b0:4a9:2ca6:c14b with SMTP id
 g3-20020ac24d83000000b004a92ca6c14bmr1311944lfe.163.1668703571595; Thu, 17
 Nov 2022 08:46:11 -0800 (PST)
MIME-Version: 1.0
References: <20221113204858.4062163-1-philipp.tomsich@vrull.eu>
 <71d8d0ca-c249-28fd-7327-5a3b932dad94@gmail.com> <CAAeLtUAMq=XiECQp=giT6o=oeZeAg4W-3f_OH6p3=TeFt6GsFQ@mail.gmail.com>
 <b622499f-eed1-fd43-cc18-ac828dd916d4@gmail.com>
In-Reply-To: <b622499f-eed1-fd43-cc18-ac828dd916d4@gmail.com>
From: Philipp Tomsich <philipp.tomsich@vrull.eu>
Date: Thu, 17 Nov 2022 17:46:00 +0100
Message-ID: <CAAeLtUDb0mY+_f_oXw8sdmQ1x-vnzruqK5dNpcfO+CQavWCzPA@mail.gmail.com>
Subject: Re: [PATCH] RISC-V: Handle "(a & twobits) == singlebit" in branches
 using Zbs
To: Jeff Law <jeffreyalaw@gmail.com>
Cc: gcc-patches@gcc.gnu.org, Christoph Muellner <christoph.muellner@vrull.eu>, 
	Kito Cheng <kito.cheng@gmail.com>, Vineet Gupta <vineetg@rivosinc.com>, 
	Jeff Law <jlaw@ventanamicro.com>, Palmer Dabbelt <palmer@rivosinc.com>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no 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 Thu, 17 Nov 2022 at 17:39, Jeff Law <jeffreyalaw@gmail.com> wrote:
>
>
> On 11/17/22 08:12, Philipp Tomsich wrote:
> >
> > This serves as an assertion only, as that case is non-sensical and
> > will be optimized away by earlier passes (as "a & C == T" with C and T
> > sharing no bits will always be false).
> > IFAIK the preceding transforms should always clean such a check up,
> > but we can't exclude the possibility that with enough command line
> > overrides and params we might see such a non-sensical test making it
> > all the way to the backend.
>
> Good!  I was thinking in the back of my mind that the no-sharing-bits
> case should have been handled in the generic optimizers.  Thanks for
> clarifying.
>
>
> >
> > What would you recommend? Adding this to the pattern's condition feels
> > a bit redundant.
>
> We can leave it in the splitter.
>
>
> > In fact, I am leaning towards hiding the !SMALL_OPERAND check in yet
> > another predicate that combines const_twobits_operand with a
> > match_test for !SMALL_OPERAND.

I'll send a v2 with this cleaned up (and look into clarifying things
around the FAIL).

Philipp.