From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <richard.guenther@gmail.com>
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c])
	by sourceware.org (Postfix) with ESMTPS id D68313858CDA
	for <gcc-patches@gcc.gnu.org>; Mon, 26 Sep 2022 07:53:54 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D68313858CDA
Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com
Received: by mail-ej1-x62c.google.com with SMTP id sb3so12221195ejb.9
        for <gcc-patches@gcc.gnu.org>; Mon, 26 Sep 2022 00:53:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date;
        bh=Q6R0W30QK4FRkjjaGotNNJf/iBm5Ok6Mo0JuF3jbJWk=;
        b=JDZqudj9iP+xrRs4AKY5nxjJN7nxbqeUowPKndDm1q7pvuaDHVX/BtkuuwsOF7PAwO
         BRqSppv+NRZtb0yPHEKp31D6z4VdyUVZiKSCX1IBW4dukCZ1j0KqiSYxC2WlAAYDdx5R
         ErjWibvF9FJaGdxq2A8H4gzWPYBZttw9RqAKAqTT59h3X20FKN6b/K24c1nnvveLHkAU
         SCtY8KunYkTB1JAtYmY0LVcb+plD51o4tUMDRZgbaZjXjJkzZOjjAqpN+6cwMaqBMrdc
         xoKjnp+bnBcC4GBE0qsFjrtYABj6JZp4tkSqv7s/q+oOP6cgjwh6nRo0uOpA7SrNnFdX
         zKZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date;
        bh=Q6R0W30QK4FRkjjaGotNNJf/iBm5Ok6Mo0JuF3jbJWk=;
        b=J7S3xckjFZ5qcYrkmKPRBYFlm4nzfYBeIrTrujuzZMcSaEXagv85Jrj2KvzweMifS1
         gmhZIt4yvrXLVK6MK/OLJy0bJSgNB+wBIwU7u1WG5KT7OG6/99hLu/7nK+QaDpJkZBGz
         O45Vu520lE+ZU/brKcGUpOKHe0lpjs5f3iluZ02tzQ+wX67+KDBuqZ5sz8fuExK4s8+y
         dOYZmDhtRwKhDnT/oTZhqS4moAu8XAS1RiOgDau2+SFOjzwcE8R+zCzZOYYpd/h077EV
         yjUX0iVjAkCGdTuYVsad0QBUZwrcQXOEiUuCtz2k/wpS3v3kSBoBqvkG6OfjaRPaJUc5
         M58g==
X-Gm-Message-State: ACrzQf157JYuMi4dvHYLOmMkLcNph8k9B+gUrF8yQU9bj9FkbqRiLwUp
	jt4ndZxx+fGor4l0k49j+YIQR5l4+/zZoFxERu8COCmc
X-Google-Smtp-Source: AMsMyM7ih+UFt+Y5+37S0Twx/RRCx1OCM1xB/WMuqXEvreHNN9JMfFZBITCMFFUw6UpXmuKRpF+bEL+ZilEfmC4kFOU=
X-Received: by 2002:a17:907:c0e:b0:783:a5c3:eafc with SMTP id
 ga14-20020a1709070c0e00b00783a5c3eafcmr1862376ejc.29.1664178833454; Mon, 26
 Sep 2022 00:53:53 -0700 (PDT)
MIME-Version: 1.0
References: <ada747e8-6ba5-70f9-f7a8-eb1685b3b09b@ventanamicro.com>
In-Reply-To: <ada747e8-6ba5-70f9-f7a8-eb1685b3b09b@ventanamicro.com>
From: Richard Biener <richard.guenther@gmail.com>
Date: Mon, 26 Sep 2022 09:53:41 +0200
Message-ID: <CAFiYyc2z=N7Yy9zsdie0X302TTJYhkDMV2mM-40mq7Lrq0-R-Q@mail.gmail.com>
Subject: Re: [RFA] Minor improvement to coremark, avoid unconditional jump to return
To: Jeff Law <jlaw@ventanamicro.com>
Cc: gcc-patches@gcc.gnu.org
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-2.2 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.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <gcc-patches.gcc.gnu.org>

On Sun, Sep 25, 2022 at 6:29 PM Jeff Law <jlaw@ventanamicro.com> wrote:
>
> This is a minor improvement for the core_list_find routine in coremark.
>
>
> Basically for riscv, and likely other targets, we can end up with an
> unconditional jump to a return statement.    This is a result of
> compensation code created by bb-reorder, and no jump optimization pass
> runs after bb-reorder to clean this stuff up.
>
> This patch utilizes preexisting code to identify suitable branch targets
> as well as preexisting code to emit a suitable return, so it's pretty
> simple.  Note that when we arrange to do this optimization, the original
> return block may become unreachable. So we conditionally call
> delete_unreachable_blocks to fix that up.
>
> This triggers ~160 times during an x86_64 bootstrap.  Naturally it
> bootstraps and regression tests on x86_64.
>
> I've also bootstrapped this on riscv64, regression testing with qemu
> shows some regressions, but AFAICT they're actually qemu bugs with
> signal handling/delivery -- qemu user mode emulation is not consistently
> calling user defined signal handlers.  Given the same binary, sometimes
> they'll get called and the test passes, other times the handler isn't
> called and the test (of course) fails. I'll probably spend some time to
> try and chase this down for the sake of making testing easier.
>
>
> OK for the trunk?

OK.

Thanks,
Richard.

>
>
> Jeff
>
>
>
>