From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) by sourceware.org (Postfix) with ESMTPS id 041133857C62 for ; Wed, 30 Sep 2020 06:25:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 041133857C62 Received: by mail-ed1-x542.google.com with SMTP id j2so546762eds.9 for ; Tue, 29 Sep 2020 23:25:33 -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:cc; bh=UAo3Nfwclugx9zCVi8iNL3WAsYsbwuFcFbt6rX3VYkI=; b=tqLOUh5V8qWbrqPeE+55KVTCM/I7MHTAUmEjQL6IhS4DMbmeQMjfG6ei3rQ6s46R5/ K3G5dUZ2UHfjaqQvhlIqU4gXFvwccoqHE9EymCdJSWwl1fg1zFHEA4L/Qa3Q3e+v0tr1 yJbNdVqAku71Nt7wBd05JgXcGAHPou0IdLIk49bIfHtwIFoCtZLnMpGlnoNIpQf20an6 ndYET92ikUl0tT5kXBvvD8YGCxBU9+wIiAN73fDo9Z6JPUZgplxhCSIfDkNU7joU5zr3 b8r0fU0ef6yq4L21ZYCwiEzdhgT/n9VvXYzXpIxnIZML8pTYPjz6BkSFv9bD/pQdPHiD mCWQ== X-Gm-Message-State: AOAM531UiNC2SC44z5Uhq6Q+kmRS3+DP1R5RKPPL+gzl24VhYzowSub7 mHhD3rHgNAkgfAVHzcyzkHfow07vbYLBabQtsxl9eKY1 X-Google-Smtp-Source: ABdhPJwLQPT/aBmbG1boYYSXZk2d+cuoCdNulnEAhQXoi3paC/9crbsr94bPNAl5Cumqe36VALfcO8oWXz+pm18/bTs= X-Received: by 2002:aa7:d783:: with SMTP id s3mr1109229edq.214.1601447132922; Tue, 29 Sep 2020 23:25:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Wed, 30 Sep 2020 08:25:21 +0200 Message-ID: Subject: Re: [PATCH] assorted improvements for fold_truth_andor_1 To: Alexandre Oliva Cc: GCC Patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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: Wed, 30 Sep 2020 06:25:36 -0000 On Tue, Sep 29, 2020 at 3:07 PM Alexandre Oliva wrote: > > On Sep 29, 2020, Richard Biener wrote: > > > On Tue, Sep 29, 2020 at 9:23 AM Alexandre Oliva wrote: > > >> On Sep 28, 2020, Richard Biener wrote: > > > ifcombine should stop using fold*, yeah > > Wow, that's quite a lot of work for no expected improvement in codegen. > I don't expect to be able to justify such an undertaking :-( > > > I also think it will not end up using the simplifications using loads. > > Yeah, ifcombine's bb_no_side_effects_p gives up on any gimple_vuse in > the inner block. that won't do when the whole point is to merge loads > from memory. > > That seems excessive. Since we rule out any memory-changing side > effects, I suppose we could get away with checking for volatile operands > there. Then, adding just a little SSA_DEF chasing, I believe I could > bring all of the fold_truth_andor_1 logic I've worked on into ifcombine > without much difficulty, and then we could do away with at least that > part of fold_truth_andor. The current restrictions were for sure to make my life easier at start when implementing the pass ;) Note that you have to watch out for short-circuited stmts that may trap or invoke undefined behavior at runtime. > > Specifically your patch seems to introduce splitting of loads > > at alignment boundaries > > ... when there's another compare involving a load from either side of > the crossed alignment boundary. Even on arches that can do unaligned > loads, the result is no worse, and if there are multiple fields crossing > consecutive alignment boundaries, the codegen and performance difference > can be pretty significant. Ah, OK - I didn't look that closely. > >> I *think* ifcombine could even be extended so as to reuse the > >> separate-test logic I put in, by looking for non-immediate dominating > >> outer conditions for the inner condition. A further modified version of > >> fold_truth_andor_1 could then be used to combine the separate tests. > > > I think the structure of ifcombine doesn't exactly match what > > fold_truth_andor does > > How so? AFAICT ifcombine_ifandif deals exactly with the (gimplified > version of the) structure I described in the patch that started the > thread: > > (a.x1 EQNE b.x1) ANDOR (a.y1 EQNE b.y1) Indeed. > > -- > Alexandre Oliva, happy hacker > https://FSFLA.org/blogs/lxo/ > Free Software Activist > GNU Toolchain Engineer