From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by sourceware.org (Postfix) with ESMTPS id 174F73858403 for ; Wed, 9 Nov 2022 04:37:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 174F73858403 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dabbelt.com Received: by mail-pj1-x1032.google.com with SMTP id gw22so15657650pjb.3 for ; Tue, 08 Nov 2022 20:37:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=AkxQ2k6Xxx6/mk9z+i6wmg/ZhE1XRYaV4eDPif4F+JY=; b=S7YF1qzQLylwpRDrA/UBztEuwCrQsBMFOPPcP1pqLP+NrEzl6TeD/UbMJK5BuU3RVB 7jQ+FYswI46jg5IsJLnd8cwCFTVWCsJTbbXk/yelDBpq1XV8XKamA348swhp9ktrJcAo 8X3+5jPpF3HZrS8zbo/IC7szVbzBQHOyr4742wSu6wk5BGJVCZQzJsOekMT+mJyZ62Ev DkjI2NIuEWHYeypPTd4bKkxLzQfvifXhJOoD75EYVuFlMlHrKC7+lyquQ/aQMUsXXVzc j/baouq2482eiyPLo29OFEVR+Gr0d+7uvZItNrA2WPKADJU3MBIZCbLqgxao0uuqzG4B 1uiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=AkxQ2k6Xxx6/mk9z+i6wmg/ZhE1XRYaV4eDPif4F+JY=; b=q2X7lExWaFRA6y47bTDe4dJRFurAQDg9CfTGtLms/w0aCDD0zTDYVifWSIOPbcUBuw AAyM5LPaedEuA6N7MDnp4Bs6Hrh/zxeisWH+vroHUPISIy87r/NLJKsuYlJ/NPfdWkXs K5oEP1zp6J73rWkhzJEzmk1NCTiVs1zbRxqOSobeflaA/FGJYcbsS1SuaVXyO08h/u3S tyHnIUaDEi9MO9xZYf5CIS0/2QAA6YR0acqD5/M9q1YHL7nzEQuVS4c4z9SrfuRswJEw Tdl4Xj4BjlL7MpvNlpSmviG1D9EnyHPybvXQbAL1oTI81mMSATtgk5Tg0EtnKKq22nKG kgvA== X-Gm-Message-State: ACrzQf0vqxrnDENz9ALB0OXbOVyNhVZDC0r5lKyw/2fJI8yK/FNHZXcJ 3TiLAmhXSNffdvwDjyM77Fn+4l50FqOUqQ== X-Google-Smtp-Source: AMsMyM7D6WMg2xnN6Q9RcNmv4fvSejzw4blrhRHMQZcV43JK+U9XuGVghmiu5qEpfCHnzG/54Nr2RQ== X-Received: by 2002:a17:902:cecf:b0:187:fd2:79c3 with SMTP id d15-20020a170902cecf00b001870fd279c3mr42408696plg.34.1667968677210; Tue, 08 Nov 2022 20:37:57 -0800 (PST) Received: from localhost ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id q10-20020a170902bd8a00b00186bc66d2cbsm7805788pls.73.2022.11.08.20.37.56 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Nov 2022 20:37:56 -0800 (PST) Date: Tue, 08 Nov 2022 20:37:56 -0800 (PST) X-Google-Original-Date: Tue, 08 Nov 2022 20:37:49 PST (-0800) Subject: Re: [PATCH] RISC-V: cost model for loading 64bit constant in rv32 In-Reply-To: <4613adab-643f-4718-a792-3d8b980c2862.sinan.lin@linux.alibaba.com> CC: gcc-patches@gcc.gnu.org From: Palmer Dabbelt To: gcc-patches@gcc.gnu.org Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,KAM_NUMSUBJECT,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no 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 Tue, 08 Nov 2022 19:26:01 PST (-0800), gcc-patches@gcc.gnu.org wrote: > loading constant 0x739290001LL in rv32 can be done with three instructions > output: > li a1, 7 > lui a1, 234128 > addi a1, a1, 1 Probably more useful to load the constant into two different registers? The point is the same, though, so just a commit message issue. > Similarly, loading 0x839290001LL in rv32 can be done within three instructions > expected output: > li a1, 8 > lui a1, 234128 > addi a1, a1, 1 > However, riscv_build_integer does not handle this case well and makes a wrong prediction about the number of instructions needed and then the constant is forced to put in the memory via riscv_const_insns and emit_move_insn. > real output: > lui a4,%hi(.LC0) > lw a2,%lo(.LC0)(a4) > lw a3,%lo(.LC0+4)(a4) > .LC0: > .word958988289 > .word8 That's still 3 instructions, but having loads and a constant is worse so that's just another commit message issue. > comparison with clang: > https://godbolt.org/z/v5nxTbKe9 IIUC the rules are generally no compiler explorer links (so we can preserve history) and no attachment patches (ie, inline them like git-send-email does). There's some documenation on sending patches at . Given those usually show up for first-time contributors there's also some copyright/DCO procedures to bo followed. I see some other linux.alibaba.com emails called out explicitly, but then also a generic "GCC Alibaba Group Holding Limited". I think that means we're OK for copyright assignment here? There's still the "you wrote the code" bits that are worth reading, though. Looking at the attached patch: > + if ((value > INT32_MAX || value < INT32_MIN) && !TARGET_64BIT) > + { > + unsigned HOST_WIDE_INT loval = sext_hwi (value, 32); > + unsigned HOST_WIDE_INT hival = sext_hwi ((value - loval) >> 32, 32); > + struct riscv_integer_op alt_codes[RISCV_MAX_INTEGER_OPS], > + hicode[RISCV_MAX_INTEGER_OPS]; > + int hi_cost, lo_cost; > + > + hi_cost = riscv_build_integer_1 (hicode, hival, mode); > + if (hi_cost < cost) > + { > + lo_cost = riscv_build_integer_1 (alt_codes, loval, mode); > + if (lo_cost + hi_cost < cost) > + { > + memcpy (codes, alt_codes, > + lo_cost * sizeof (struct riscv_integer_op)); > + memcpy (codes + lo_cost, hicode, > + hi_cost * sizeof (struct riscv_integer_op)); > + cost = lo_cost + hi_cost; > + } > + } > + } This kind of stuff always seems like it should be possible to handle with generic middle-end optimizations: it's essentially just splitting the 64-bit constant into two 32-bit constants, which is free because it's going into two registers anyway. That's not a RISC-V specific problem, it's just the case any time a constant is going to be split between two registers -- it'd even apply for 128-bit constants on rv64, though those are probably rare enough they don't matter all that much. I'm not opposed to doing this in the backend, but maybe it's a sign we've just screwed something else up and can avoid adding the code? > +++ b/gcc/testsuite/gcc.target/riscv/rv32-load-64bit-constant.c > @@ -0,0 +1,35 @@ > +/* { dg-do compile } */ > +/* { dg-options "-march=rv32gc -mabi=ilp32 -Os" } */ This has the same library/abi problems we've had before, but in this case I think it's fine to just leave the -march/-mabi out: the test cases won't be that exciting on rv64 (unless we add the 128-bit splits too?), but they should still stay away from the constant pool. IIUC this should work on more than Os, at least O2/above? Not that exciting for the test case, though. > +/* { dg-final { scan-assembler-not "\.LC\[0-9\]" } } */ That's a bit fragile, maybe just match on load-word?