From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sourceware.org (Postfix) with ESMTPS id 35BBB3858D35 for ; Fri, 31 Jul 2020 13:13:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 35BBB3858D35 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="462039853" Received: from 85-171-191-139.rev.numericable.fr (HELO stedding) ([85.171.191.139]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jul 2020 15:13:11 +0200 Date: Fri, 31 Jul 2020 15:13:11 +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_H4, 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:13:13 -0000 On Fri, 31 Jul 2020, Marc Glisse wrote: > 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. That was for rounding. -ftrapping-math does not disable folding of typedef double vecf __attribute__((vector_size(16))); typedef long long veci __attribute__((vector_size(16))); vecf f(veci c){ vecf z={}; return (z+1)/(z+3); } despite a possible inexact flag, so it doesn't disable vec_cond_expr folding either. (not sure we want to fix this unless -fno-trapping-math becomes the default) -- Marc Glisse