From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 7828F3858C48 for ; Mon, 17 Jun 2024 08:58:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7828F3858C48 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7828F3858C48 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718614736; cv=none; b=dv98/SieYlj7Fg1I1nFWf0In8eDMrrwGC6OaQVUT0+ihUJAQ4SOyFJaBLYYo2JnSME+Cw61E7RGSrsTxHCjhZcq4yoLgYo6IK9DpkzEC78R3S/Lazk559FCjsxg8vjUcPKA7IFjU1ZmwdHG9GhpH659BBj4YdAG2P1vJMU+xxNI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718614736; c=relaxed/simple; bh=H8c79L1XeV0PSn0T8cD7xboY+NLh0DElEOkV/2DixHk=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=GRttyDvCgU0h2JvSsPjMFv1tgqiOz4/FBCCcASlzL+Kdvf5tS0CZM1DLRscNKRkjkpPHntwRVdzOXwwf7Xp7o88d9yBRuTnvXJzEUgP8/fGriqKZqtGseo5dMk/d0auKNQ37puurq163vtTwb/mzyzf9fcTJ/cXtOu+Bc8jfWJ4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1718614734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+nHzX0CJUmT8pZy3fLRckFlqGHcCpC1GqIGR+gtuPGk=; b=SvFM1enjkPb7qjtYOSebgRTnxKHidZE/TFhNlq6gzp8rh0M+XgrriwTW5G417bdS/fgpbR Bl+/LlJVSortaI7Z62GzEN68Vt7AGPNB74EBzUgKIR9qHAfLGp0BJXOJQPhodzWjQO3Oni 9ZFwiAdXvwfviVK4oFQ1s+riXUph8hE= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-481-6q68u9jsMXKW32as2rioyQ-1; Mon, 17 Jun 2024 04:58:49 -0400 X-MC-Unique: 6q68u9jsMXKW32as2rioyQ-1 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-421f3b7b27eso36181675e9.1 for ; Mon, 17 Jun 2024 01:58:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718614728; x=1719219528; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+nHzX0CJUmT8pZy3fLRckFlqGHcCpC1GqIGR+gtuPGk=; b=Nl+33TF/yoPIkjAQ+WO1psT8yNJA/xFLyvmzhwLterc+6VZfEJqM/CpF4UOq83zfvY WMTHSBPaW0OVEtywPGSIchD2VwCgIyBPBsA0T6E84PvVzN8riGlkG4A7G7KCJwkEs4Tx N8dpvi6HOuhB3Mu1e1quX4JfjJgYNncKxcBaJ9Dnx3lnCQ9y8eeJBKKxRFSEH5bhC7sg xzAzmmrDXoJLSTRbkdieqQdj+sQ8uw2rT9G4xua2/PLfj3TDRLF2iKDTlb1N95M9oAqJ b6wqvprGCLZ4oTkNo4pPYTPB+9YbB2mOoknpos08+Rzu3pQgn6EV7w3pH0K+vhOUuB3n ZEkQ== X-Forwarded-Encrypted: i=1; AJvYcCWsrlVtLaIm8i+Z8zUErXVLCXNvc7+wv84ndcXPmd6AJnlyH+Tgqrx8Wpy9XBPisuG7ud63O0PQqlKkhxMARpEDqFPIIWUESR59qg== X-Gm-Message-State: AOJu0YzkCB3g8/xw+tmyh1qpb94I8aeJ6700QG/Np6B2uupeR9UrE5YZ +5Sxxw7uLsbdjFW8p5DBLd/X1LuSCqI8KZPFLgFQzB3c3rJRAD6yhiNq5jOBlIwy03hGSfjC6lS /pG/f7sxwn9ZjHbydadekxRaUT+6dzU9grPyDKH+ZRpxVRUnPSgPcL6wtcWg= X-Received: by 2002:a05:600c:4f49:b0:422:6755:17de with SMTP id 5b1f17b1804b1-4230485678cmr83326205e9.41.1718614727861; Mon, 17 Jun 2024 01:58:47 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEjA9vifHcmeON2NHxPQk6LPhH1JXD4e4oSFiM3kNl5la4ByN/GWyGuzkEZUvX1lQmRuH7VrA== X-Received: by 2002:a05:600c:4f49:b0:422:6755:17de with SMTP id 5b1f17b1804b1-4230485678cmr83326005e9.41.1718614727273; Mon, 17 Jun 2024 01:58:47 -0700 (PDT) Received: from localhost ([31.111.84.186]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-422f9e2b306sm151861745e9.16.2024.06.17.01.58.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Jun 2024 01:58:47 -0700 (PDT) From: Andrew Burgess To: Bernd Edlinger , "gdb-patches@sourceware.org" Subject: Re: [PATCH 2/2] sim: riscv: Simplify the signed div by -1 code In-Reply-To: References: <87frtja1kr.fsf@redhat.com> Date: Mon, 17 Jun 2024 09:58:46 +0100 Message-ID: <875xu86j3t.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-11.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: Bernd Edlinger writes: > On 6/11/24 18:25, Andrew Burgess wrote: >> Bernd Edlinger writes: >> >>> This uses the idea from the previous patch to >>> simplify the code for non-overflowing signed >>> divisions by -1. This is no bug-fix but it >>> simplifies the code and avoids some unnecessary >>> branches. >>> --- >>> sim/riscv/sim-main.c | 10 ++++------ >>> 1 file changed, 4 insertions(+), 6 deletions(-) >>> >>> diff --git a/sim/riscv/sim-main.c b/sim/riscv/sim-main.c >>> index 515ff835223..e4b15b533ba 100644 >>> --- a/sim/riscv/sim-main.c >>> +++ b/sim/riscv/sim-main.c >>> @@ -700,18 +700,16 @@ execute_m (SIM_CPU *cpu, unsigned_word iw, const struct riscv_opcode *op) >>> const char *rd_name = riscv_gpr_names_abi[rd]; >>> const char *rs1_name = riscv_gpr_names_abi[rs1]; >>> const char *rs2_name = riscv_gpr_names_abi[rs2]; >>> - unsigned_word tmp, dividend_max; >>> + unsigned_word tmp; >>> sim_cia pc = riscv_cpu->pc + 4; >>> >>> - dividend_max = -((unsigned_word) 1 << (WITH_TARGET_WORD_BITSIZE - 1)); >> >> I really don't understand what this was trying to calculate. It's not >> the max value of an unsigned_word. Nor is it the bit representation of >> the maximum signed_word value... but you're removing it, so I guess I >> can not worry about that :) >> > > This is the largest negative dividend, either -2**31=-2147483648 or -2**63=-9223372036854775808 I guess my definition of 'max' and 'min' differ from whoever wrote this code! I'd describe those values as 'dividend_min'. But as the code is going away it's really not important. > and dividing this value by any non-negative value is always fine, except for the divisor=-1, > because the result will overflow, and can therefore cause problems. Ah, got you. This for sure should have a comment explaining the reasoning. > > But by my reasoning I found a simple solution that handles the divisor -1 for all dividends > correctly and more efficiently, by simply computing -(unsigned)x instead of x/-1. > >>> - >>> switch (op->match) >>> { >>> case MATCH_DIV: >>> TRACE_INSN (cpu, "div %s, %s, %s; // %s = %s / %s", >>> rd_name, rs1_name, rs2_name, rd_name, rs1_name, rs2_name); >>> - if (riscv_cpu->regs[rs1] == dividend_max && riscv_cpu->regs[rs2] == -1) >>> - tmp = dividend_max; >>> + if (riscv_cpu->regs[rs2] == -1) >>> + tmp = -riscv_cpu->regs[rs1]; >> >> As with the previous commit, can't we drop this whole if check and block? >> > > No in this case the division would indeed overflow on the division dividend_max/-1. Agree. Just add a comment explaining this please. > >> I think we should add some tests for this too. The test I proposed in >> the previous commit can be modified to give us div.s and rem.s tests. >> > > Well, since this is just refactoring, and there is already very good test > coverage in the gcc testsuite, I would not do that here, but instead The simulator should have tests in the simulator tree so I think we need to add tests. As I've already supplied a rough framework for the previous commit, which I believe you're going to polish for that test, all you need to do here is copy that framework, change divw to div, and fill in a few interesting test cases, so it shouldn't take long. > I think the overflow bug in the mulh instruction really deserves a test case: > > [PATCH] sim: riscv: Fix undefined behaviour in mulh and similar > https://sourceware.org/pipermail/gdb-patches/2024-April/208616.html > > So I will post an update for this one with a test case that demonstrates > the possible mis-compilation due to a compiler optimization based on the > assumption that an undefined behaviour may never happen, which caused > user visible effects in this case. Great, the more tests the better. Thanks, Andrew