From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by sourceware.org (Postfix) with ESMTPS id 113A93858D35 for ; Tue, 4 Jul 2023 14:32:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 113A93858D35 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-pj1-x1035.google.com with SMTP id 98e67ed59e1d1-2633fe9b6c0so3549546a91.1 for ; Tue, 04 Jul 2023 07:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrull.eu; s=google; t=1688481160; x=1691073160; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=q8e/L3EUjTU+TcUJnJFe98o+/2PixKhzItcVh36qBvA=; b=KXtYY9x6Ggv1zmmTSvXio5ZyezMRJOu1Exvuh4g1FSNAVFWL+Mcgbhu0BrfMnAYsHW /cqViITwhI56gRmkPQX8hUX2fLuIXlRwXeSXn57eAeOVip+tPLvYTxF8RZbOpLwhwLUb JliththGAoB0inn7lo1Wh87mJUiMapeEeN9iYGVwAfRPvT0bunyUZ6D4KRbvU1qKnYsJ GTaapT5ZTu1JtaRAuOiVYmMN3ECRr2EFbWuoiajnmjv05h5WfSWq7kNZRuj1xqZ8xE6m X7uitm7avDglfd30CT8W6nflHZFIuADcAG7G5btlgT+OswZqhciZeu/0AdKSvKWsoadd IjUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688481160; x=1691073160; h=content-transfer-encoding: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=q8e/L3EUjTU+TcUJnJFe98o+/2PixKhzItcVh36qBvA=; b=YKtYlCsreFCj4qOCYB7u37kZ2Us2j47h7Z//NHt9EecStt3ZpHUjFL94TZ0Uhap4Uy cPP3gnDtFMYU8qYakIgQ219sGiCLZSj5MldwIArgibks4RArjImKyJ2SMldtNJ3JNmkn 5wHy1lSZEy8dv3OUa5I/Q6wHYNB5WC8vsNB0Dc8sn9KU2IHJkEkW87KZLUmZwOGqiIb6 AeDDwS2jYij1kEWIs0ot6SkeAFA1P+NHCq+h/2bRWYyqwJeh/fWCMEQOtOtCxcfS20Gj QPAYvs29IyHISlQFgVQABank6RPsduPL/KZukJGFRG/65djU1J9lMBaAUa72LDH2GxIs +ZPg== X-Gm-Message-State: AC+VfDzwJx8C1+67/dSGAdySo34AtJuNCOWePIzgekglxuMsom0WQy4v RSNscrTFVta0LlqhW5ual1g4E1p8pb+gJCNeYxOn/g== X-Google-Smtp-Source: ACHHUZ6xGj/Clb92Trq4hiaprWB0S88Uzdp8VvqotWM0fmatn/Rp1SoheYn4mDmWSsOEx2cOlDnrrfeYXc9t7sTWMSM= X-Received: by 2002:a17:90a:7005:b0:262:ca9c:edcb with SMTP id f5-20020a17090a700500b00262ca9cedcbmr25800126pjk.9.1688481159820; Tue, 04 Jul 2023 07:32:39 -0700 (PDT) MIME-Version: 1.0 References: <20230701092413.2488806-1-manolis.tsamis@vrull.eu> <20230701092413.2488806-3-manolis.tsamis@vrull.eu> In-Reply-To: From: Manolis Tsamis Date: Tue, 4 Jul 2023 17:32:03 +0300 Message-ID: Subject: Re: [PATCH 2/2] ifcvt: Allow more operations in multiple set if conversion To: Robin Dapp Cc: gcc-patches@gcc.gnu.org, Jakub Jelinek , Philipp Tomsich , Andrew Pinski Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.1 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,T_SCC_BODY_TEXT_LINE 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: On Mon, Jul 3, 2023 at 12:12=E2=80=AFPM Robin Dapp wr= ote: > > Hi Manolis, > > that looks like a nice enhancement of what's already possible. The conce= rn > I had some years back already was that this function would eventually > grow and cannibalize on some of what the other functions in ifcvt already > do :) At some point we really should unify but that's not within the > scope of this patch. > Hi Robin, Indeed and it would be nice to extend the multi statement implementation to the point that the others are not needed :) I have some future plans to analyze cases where the multi-statement performs worse and improve on that. > IMHO we're already pretty far towards general "conditional execution" > with conditional increments, selects and so on (and the function is still > called "_noce") and historically the cond_exec functions would have > taken care of that. To my knowledge though, none of the major backends > implements anything like (cond_exec ...) anymore and relies on bit-twiddl= ing > tricks to generate the conditional instructions. > > Have you checked whether cond_exec and others could be adjusted to > handle the conditional instructions you want to see? They don't perform > full cost comparison though but just count. > Thanks for mentioning that, I was not really aware of cond_exec usage. As you say, it looks like cond_exec isn't used very much on major backends. Since noce_convert_multiple_sets_1 is just using the existing ifcvt machinery (specifically noce_emit_cmove / try_emit_cmove_seq), is this a question of whether we want to replace (if_then_else ...) with (cond_exec ...) in general? If that is beneficial then I could try to implement a change like this, but that should probably be a separate effort from this implementation. > I would expect a bit of discussion around that but from a first look > I don't have major concerns. > > > -/* Return true iff basic block TEST_BB is comprised of only > > - (SET (REG) (REG)) insns suitable for conversion to a series > > - of conditional moves. Also check that we have more than one set > > - (other routines can handle a single set better than we would), and > > - fewer than PARAM_MAX_RTL_IF_CONVERSION_INSNS sets. While going > > +/* Return true iff basic block TEST_BB is suitable for conversion to a > > + series of conditional moves. Also check that we have more than one > > Might want to change the "conditional moves" while you're at it. > Thanks for pointing out this comment, I missed it. I will rewrite the relevant parts. > > > > - if (!((REG_P (src) || CONSTANT_P (src)) > > - || (GET_CODE (src) =3D=3D SUBREG && REG_P (SUBREG_REG (src)) > > - && subreg_lowpart_p (src)))) > > + /* Allow a wide range of operations and let the costing function= decide > > + if the conversion is worth it later. */ > > + enum rtx_code code =3D GET_CODE (src); > > + if (!(CONSTANT_P (src) > > + || code =3D=3D REG > > + || code =3D=3D SUBREG > > + || code =3D=3D ZERO_EXTEND > > + || code =3D=3D SIGN_EXTEND > > + || code =3D=3D NOT > > + || code =3D=3D NEG > > + || code =3D=3D PLUS > > + || code =3D=3D MINUS > > + || code =3D=3D AND > > + || code =3D=3D IOR > > + || code =3D=3D MULT > > + || code =3D=3D ASHIFT > > + || code =3D=3D ASHIFTRT > > + || code =3D=3D NE > > + || code =3D=3D EQ > > + || code =3D=3D GE > > + || code =3D=3D GT > > + || code =3D=3D LE > > + || code =3D=3D LT > > + || code =3D=3D GEU > > + || code =3D=3D GTU > > + || code =3D=3D LEU > > + || code =3D=3D LTU > > + || code =3D=3D COMPARE)) > > We're potentially checking many more patterns than before. Maybe it > would make sense to ask the backend whether it has a pattern for > the respective code? > Is it an issue if the backend doesn't have a pattern for a respective code? My goal here is to not limit if conversion for sequences based on the code but rather let ifcvt / the backedn decide based on costing. That's because from what I've seen, conditional set instructions can be beneficial even when the backend doesn't have a specific instruction for that code. Best, Manolis > Regards > Robin >