From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sourceware.org (Postfix) with ESMTPS id 827AC3851C19 for ; Fri, 31 Jul 2020 13:01:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 827AC3851C19 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=inria.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=marc.glisse@inria.fr X-IronPort-AV: E=Sophos;i="5.75,418,1589234400"; d="scan'208";a="355710414" Received: from 85-171-191-139.rev.numericable.fr (HELO stedding) ([85.171.191.139]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jul 2020 15:01:18 +0200 Date: Fri, 31 Jul 2020 15:01:18 +0200 (CEST) From: Marc Glisse X-X-Sender: glisse@stedding.saclay.inria.fr To: Richard Sandiford cc: gcc-patches@gcc.gnu.org Subject: Re: VEC_COND_EXPR optimizations In-Reply-To: Message-ID: References: User-Agent: Alpine 2.23 (DEB 453 2020-06-18) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 13:01:21 -0000 On Fri, 31 Jul 2020, Richard Sandiford wrote: > Marc Glisse writes: >> On Fri, 31 Jul 2020, Richard Sandiford wrote: >> >>> Marc Glisse 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 = NULL; >>>> + rhs1 = fold_binary (op, type, @1, @3); >>>> + if (rhs1 && is_gimple_val (rhs1)) >>>> + rhs2 = 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 too >> optimistic? > > Not sure TBH. I was thinking of “trapping” in the sense of raising > an IEEE exception, rather than in the could-throw/must-end-bb sense. That's what I understood from your message :-) > I thought match.pd applied to things like FP addition as normal and > it was up to individual patterns to check the appropriate properties. Yes, and in this case I am delegating that to fold_binary, which already performs this check. I tried with this C++ program typedef double vecf __attribute__((vector_size(16))); typedef long long veci __attribute__((vector_size(16))); vecf f(veci c){ return (c?1.:2.)/(c?3.:7.); } the folding happens by default, but not with -frounding-math, which seems like exactly what we want. -- Marc Glisse