public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@embecosm.com>
To: Kito Cheng <kito.cheng@gmail.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
	Andrew Waterman <andrew@sifive.com>,
	Jakub Jelinek <jakub@redhat.com>
Subject: Re: [PING][PATCH] RISC-V: Standardize formatting of SFB ALU conditional move
Date: Thu, 18 Aug 2022 16:54:02 +0100 (BST)	[thread overview]
Message-ID: <alpine.DEB.2.20.2208181615440.19931@tpp.orcam.me.uk> (raw)
In-Reply-To: <CA+yXCZDtjpaPH8yBdFmj9_g3rSOsy1DsWv8BP33qV19zJnqvNg@mail.gmail.com>

On Thu, 18 Aug 2022, Kito Cheng wrote:

> OK, thanks for tweaking this!

 Committed now, thanks for your review!

 Would you mind sharing your opinion on my previous observation here:
<https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598542.html>?

 I have since realised we have a `-mbranch-cost=' option letting the user 
set the threshold for choosing branches over alternative code sequences, 
so my concern is valid even for our tree unchanged and without the change 
just committed here applied.  Consequently the test case may fail.

 E.g. with:

RUNTESTFLAGS="--target_board remote-unmatched/-mbranch-cost=1 riscv.exp=pr105314.c"

I get:

PASS: gcc.target/riscv/pr105314.c   -O0  (test for excess errors)
FAIL: gcc.target/riscv/pr105314.c   -O0   scan-assembler-not \tbeq\t
PASS: gcc.target/riscv/pr105314.c   -O1  (test for excess errors)
FAIL: gcc.target/riscv/pr105314.c   -O1   scan-assembler-not \tbeq\t
[...]

		=== gcc Summary ===

# of expected passes		9
# of unexpected failures	9

because GCC legitimately chooses to emit branches as less costly in this 
case.

 I think we need to pacify the test case somehow if it does not match the 
criteria for PR105314, either by excluding the case from testing in that 
situation or by forcing it via command-line options to make it match the 
criteria (or indeed by verifying a branch is produced regardless).  Sadly 
Jakub chose not to chime in and it's not clear to me which approach would 
be the most appropriate here.

  Maciej

      reply	other threads:[~2022-08-18 15:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-26 18:38 [PATCH] " Maciej W. Rozycki
2022-08-18 14:40 ` [PING][PATCH] " Maciej W. Rozycki
2022-08-18 14:47   ` Kito Cheng
2022-08-18 15:54     ` Maciej W. Rozycki [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.20.2208181615440.19931@tpp.orcam.me.uk \
    --to=macro@embecosm.com \
    --cc=andrew@sifive.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=kito.cheng@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).