From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <richard.guenther@gmail.com>
Received: from mail-ej1-x644.google.com (mail-ej1-x644.google.com
 [IPv6:2a00:1450:4864:20::644])
 by sourceware.org (Postfix) with ESMTPS id D56A03851C19
 for <gcc-patches@gcc.gnu.org>; Fri, 31 Jul 2020 12:59:16 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D56A03851C19
Received: by mail-ej1-x644.google.com with SMTP id a26so5527144ejc.2
 for <gcc-patches@gcc.gnu.org>; Fri, 31 Jul 2020 05:59:16 -0700 (PDT)
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:content-transfer-encoding;
 bh=aUdCKL9zcbqnhn6ZBxiLNlottqDiyT3FSNud4pIA4Kw=;
 b=Y7JllwJ5b1l5T6dhtLf5xTNRPdLLMyn1dul2FGszaIW+HCUdIEtC5y4X8lLhJTB/A4
 TrPQz5Q9yp2heBP08g2z3lU7N5cEgaqBkiCLCWQgEHh4P+HCuMwPcgB38z8omidI+sk4
 EVB2lzfqCHxsIaOfmxZNX2tq5imXOMsnCMqeLjGv8MtnL5IonRVjevdADkTOR1dTOAw5
 Of2E4t9oZBvtKSJqj85NINf8gIL2RjKVS2xlfXZW6RVqr4g/rHmIeu/6zDAj+9fQPc2p
 sEFyAcL/S8aN6M26kYoq29/MuEY5vbIM/2xbl76ZKrMHc9wrdSZALLu/HrcssjYIrtBM
 PrZQ==
X-Gm-Message-State: AOAM533HQbtA8kTzrMtzhWK9AZJvry8r3TZGKuEiihlmKfMuiK/BsbgS
 UwNQvcAxT6A5hfBsMmq0LE98fDcVw8jMJjhn2BXbOA==
X-Google-Smtp-Source: ABdhPJxTLIdwpBv5KleDDnBHfyWHqkJPitIQf50swwbRze+AZ1Nw91UvSm72iS4GYnxmP7ddNaMq7rJRPivV68Xruq0=
X-Received: by 2002:a17:906:384a:: with SMTP id
 w10mr4102847ejc.235.1596200355934; 
 Fri, 31 Jul 2020 05:59:15 -0700 (PDT)
MIME-Version: 1.0
References: <alpine.DEB.2.23.453.2007291859410.6927@stedding.saclay.inria.fr>
 <mptbljwaq6g.fsf@arm.com>
 <alpine.DEB.2.23.453.2007311328550.5703@stedding.saclay.inria.fr>
 <mpt1rkrc0hj.fsf@arm.com>
In-Reply-To: <mpt1rkrc0hj.fsf@arm.com>
From: Richard Biener <richard.guenther@gmail.com>
Date: Fri, 31 Jul 2020 14:59:04 +0200
Message-ID: <CAFiYyc1anmRvh4zNeesCyCLmzh_2LDiAhTCVrW1HP0c0wMUHnA@mail.gmail.com>
Subject: Re: VEC_COND_EXPR optimizations
To: Marc Glisse <marc.glisse@inria.fr>, GCC Patches <gcc-patches@gcc.gnu.org>, 
 Richard Sandiford <richard.sandiford@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.0 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: Fri, 31 Jul 2020 12:59:18 -0000

On Fri, Jul 31, 2020 at 2:50 PM Richard Sandiford
<richard.sandiford@arm.com> wrote:
>
> Marc Glisse <marc.glisse@inria.fr> writes:
> > On Fri, 31 Jul 2020, Richard Sandiford wrote:
> >
> >> Marc Glisse <marc.glisse@inria.fr> writes:
> >>> +/* (c ? a : b) op (c ? d : e)  -->  c ? (a op d) : (b op e) */
> >>> + (simplify
> >>> +  (op (vec_cond:s @0 @1 @2) (vec_cond:s @0 @3 @4))
> >>> +  (with
> >>> +   {
> >>> +     tree rhs1, rhs2 =3D NULL;
> >>> +     rhs1 =3D fold_binary (op, type, @1, @3);
> >>> +     if (rhs1 && is_gimple_val (rhs1))
> >>> +       rhs2 =3D fold_binary (op, type, @2, @4);
> >>> +   }
> >>> +   (if (rhs2 && is_gimple_val (rhs2))
> >>> +    (vec_cond @0 { rhs1; } { rhs2; })))))
> >>> +#endif
> >>
> >> This one looks dangerous for potentially-trapping ops.
> >
> > I would expect the operation not to be folded if it can trap. Is that t=
oo
> > optimistic?
>
> Not sure TBH.  I was thinking of =E2=80=9Ctrapping=E2=80=9D in the sense =
of raising
> an IEEE exception, rather than in the could-throw/must-end-bb sense.
> I thought match.pd applied to things like FP addition as normal and
> it was up to individual patterns to check the appropriate properties.

I think it can be indeed defered to the simplification of (op @0 @2)
because that would be invalid if it removes a IEEE exception.
The VEC_COND_EXPR itself cannot trap.

Richard.

> Thanks,
> Richard