From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) by sourceware.org (Postfix) with ESMTPS id 533BE3858D3C for ; Wed, 29 Nov 2023 01:19:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 533BE3858D3C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 533BE3858D3C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::52f ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701220787; cv=none; b=omfYEevQJyv+UFvlTp61Zce73ojPSE2j5MjtgZPmSd1+XXbiSF3er3R9+b7ZbFnbKvk3R65lC7robuDGRFPgOiSZ3S+BMfd+CextkNHQaFIjVCySK6wYqlMBq9YN5JmS+s/eTaDajz4JurK/zUOuy1Ev9k9nyXz3D1s194xvGA0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701220787; c=relaxed/simple; bh=aiiKqwcZSW+UJDy9YdpHdEPMDWEm8iqKWEEmL/8+chM=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=nEi3lk4VpzblqpRwC/i8rGLtNlHOuAUtR1HPTDAAWv1+ou3AS//ldrIpFhg5016Xw1ieM+Mo9jZDpL8/P25OHwqarOZ3d1oAvSgDz3x2dJm3eSAjB6hv1EBPqm1jhC2dNmAHpBYyrE7VuGZRGGOoHz1TLCGH1oSo2pJT9mjsyG4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pg1-x52f.google.com with SMTP id 41be03b00d2f7-5c2b7ec93bbso2713288a12.2 for ; Tue, 28 Nov 2023 17:19:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701220783; x=1701825583; darn=gcc.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=7uy03YfamAoGIoTWmaB7BJboycG6OVDW34NrzOuQPzI=; b=fQYj22tAwx39laoPPfH3fADeH8u/cA8sxvQH975dnYtvd9+Sdw7O1ub+EXlCyrwrFu dkZC85N6KqPMkeFYKxGcBF5H0id6V9Ln/ozmV2YH84VUzfTX5/KVFQ34MHY1yecD8tcz HQIDtngSOxOxobSf0JxVImQ6qPXb2XoluOqUwMMjIn4BbeYRYlSbA+NsPqBmB/OvPcZX GPDbFshqdUld295xq77mLtM0j+hMwL6pbK82OFj/irU+b84mPX64Ae7F2yIZVCRPuKDR 1DWHxEoQJ6D74/ww79VMowFhdfTovc1bMIk5Ai8XxODhcaSFvjGQh/CWJg+FMlJ/Vfwi QNdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701220783; x=1701825583; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7uy03YfamAoGIoTWmaB7BJboycG6OVDW34NrzOuQPzI=; b=gLXUl7a4E2Hdq1l4XzdhO3fkNhv+lH6nxukdJRiGfi/Jel9iL797Pper+OmeHIaRpT 4zIXCg9prAkGAlnUpisoeV+f7ySZGL/HO1FAIyqV+1cpLwjc1ZR6Wz5IQ1KpNCRmx0/M 0PyYcXf6fswZxfDbLpJedqAb4FN1Fdu0VPvsvtirlJaEuCdAvtql8Kdg8X0MbkrDRx4s lYfbqxz3tDiwCmZ2VFLMUFYvBHxyA2LDLjLXUhq5TlTecttJ3MkVuKjVZIvIVKS5IQ06 3+p18MykBEJS+LnKjS69mNGh50Fth71isHzQ7eJuzqmrJTh69SpMDi/oUVBza+SRZE54 nEew== X-Gm-Message-State: AOJu0YwLYlVwkDg4H1I01d/N8vXRL5TvzuF2EH+QXaaXEgKlc+s2cseO pTPxEBX938Q8ZhjkZRsZTvE= X-Google-Smtp-Source: AGHT+IGp6aM73j/Syc/HiuU9Ucq7m7Q7tNVvQCNfo2GUhmKNoIFQJh7ISliHvyjSciykCj27XMvU9Q== X-Received: by 2002:a17:902:f550:b0:1cf:a5a0:5f85 with SMTP id h16-20020a170902f55000b001cfa5a05f85mr22943835plf.25.1701220783270; Tue, 28 Nov 2023 17:19:43 -0800 (PST) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id m7-20020a1709026bc700b001c9bfd20d0csm10865555plt.124.2023.11.28.17.19.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Nov 2023 17:19:42 -0800 (PST) Message-ID: <86917a66-8442-49d5-a2f2-fb8b991ccaf3@gmail.com> Date: Tue, 28 Nov 2023 18:19:36 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 09/44] RISC-V: Rework branch costing model for if-conversion Content-Language: en-US To: "Maciej W. Rozycki" Cc: gcc-patches@gcc.gnu.org, Andrew Waterman , Jim Wilson , Kito Cheng , Palmer Dabbelt References: <7ec2ebde-9242-4907-85d9-d76e84bea5ec@gmail.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.3 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,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: On 11/23/23 11:34, Maciej W. Rozycki wrote: > On Sun, 19 Nov 2023, Jeff Law wrote: > >> As I suspect you know a big part of the problem here is that BRANCH_COST and >> rtx_cost don't have any common scale and thus trying to compare BRANCH_COST to >> RTX_COST doesn't have well defined meaning. > > We do have preexisting places using COSTS_N_INSNS (BRANCH_COST ()) > though, as documented in ifcvt.cc: > > ??? Actually, instead of the branch instruction costs we might want > to use COSTS_N_INSNS (BRANCH_COST ()) as in other places. */ > > so it seems the right direction, and given that we expose this measure to > the user (and at the very least GCC developers implementing new tuning > microarchitectures) I think it's the only sane way to do branch costing: > define the measure in terms of how many ordinary ALU instructions a branch > is statistically equivalent to. Oh, it probably is the only sane way at this point. To do anything more sane we'd have to disassociate the BRANCH_COST uses during tree/gimple from those in RTL-land. FWIW, I was looking at a regression with our internal tests after your changes. It was quite nice to see how well twiddling -mbranch-cost correlated to how many instructions we would allow in a conditional move sequence. The downside is it highlighted the gimple vs RTL use issue. I'm confident that we would like to see a higher branch cost in the RTL phases for our uarch, but I'm much less comfortable with how that's going to change the decisions made in trees/gimple. We'll have to investigate that at some depth. > >> WRT the extraneous zero-extension. Isn't that arguably a bug in the scc >> expander for risc-v? Fixing that isn't a prerequisite here, but it probably >> worth a bit of someone's time. > > I've looked at it already and it's the middle end that ends up with the > zero-extension, specifically `convert_move' invoked from `emit_cstore' > down the call to `noce_try_store_flag_mask', to widen the output from > `cstoredi4', so I don't think we can do anything in the backend to prevent > it from happening. And neither I think we can do anything useful about > `cstoredi4' having a SImode output, as it's a pattern matched by name > rather than RTX, so we can't provide variants having a SImode and a DImode > output each both at a time, as that would cause a name clash. We're actually tracking some of these extraneous extensions. Do you happen to know if the zero-extended object happens to be (subreg:SI (reg:DI)) kind of construct? That's the kind of thing we're chasing down right now from various points. Vineet has already fixed one class of them. Jivan and I are looking at others. jeff