From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by sourceware.org (Postfix) with ESMTPS id C11803946DEA for ; Thu, 8 Dec 2022 20:21:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C11803946DEA 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-x1029.google.com with SMTP id t11-20020a17090a024b00b0021932afece4so5827340pje.5 for ; Thu, 08 Dec 2022 12:21:27 -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=NjkW/f/0J6a22pHNGSP0KJ2fWv7TUBdX6g9FKtrJHzM=; b=E5Ug3YRSTk9lqwijxzIqHYhVWbxWQKzTx77JOvcNtMhzlI97Ss2+O2c1sTcLyC6/bg m8VB6tljeRbsN6dB2E6ZWlllUfHrPTb9HDr3d/yC87RM0Ma9ZiWUkiaOh2afnTUyGWe8 Tfr5E5bunu/p92rxF1cB1MspOOcZYEqy80oR4dnFNIf9kM3Z0i6Ljj70x0wuANQI8XzW 0CEjD8YhMqNk9xOwEUuyaHtWvoFh/Pqaye/Y9LXeNRweD+NBN6Gxj1/WREK7wDUBpn3s a6Zey3tDUi8oSnWmAirdErrU5jJCD3VHoAa4ZdoaV+fNJBrnWMVy1IlZq+nhp5Ht4Evi E0vw== 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=NjkW/f/0J6a22pHNGSP0KJ2fWv7TUBdX6g9FKtrJHzM=; b=2c3Bgfr8jcnIYF+FZQwfGRqcjXmriJPHRjp7E3uuMQfjr5DckyQi2+2AY4/Vr1JYQu hu+9g3d3UsLAqLrl8oNqP84m4SZp3ihDdKPPBaZ0UwcOroOxBCtZUw040zbqDfWjVPtu P/4ZeDR+Q4+wZdMo/stB6vShwjc9vk4iWb3R8vliYtKkR3ztP9idGUL+FO/HzD7r+Vpa J3VzhENowVGHe2dmum8i6N8lAMKP6Yu4XczBH597FGcl/e64ar3zSnNgHweGKnSFXIaX 1f9pMtf9qu+JrZDiwbKy8uRmmk9ATn0Ufs4u47tNhEMHTZFKCJS9qtOBK5etpPs7U4Uy q9TQ== X-Gm-Message-State: ANoB5pm3gwm4nerZHt6zzqzds+AkV8b2d17EzpEBxIrmII5x7ZfIQ8F0 slse8gcJySFtjyIrqcS2krXgXBiT8CS/K/SQ X-Google-Smtp-Source: AA0mqf6HXOFtvYvqW8YdkrmbPlMwnn0BouAF30hzw++dor6nIhhvXcsBvS7J5pa7N5X9GLqVMfdwpA== X-Received: by 2002:a17:902:e2c2:b0:189:de2a:b10c with SMTP id l2-20020a170902e2c200b00189de2ab10cmr16180033plc.95.1670530885129; Thu, 08 Dec 2022 12:21:25 -0800 (PST) Received: from localhost ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id b18-20020a621b12000000b0057709fd0fccsm7283552pfb.153.2022.12.08.12.21.24 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Dec 2022 12:21:24 -0800 (PST) Date: Thu, 08 Dec 2022 12:21:24 -0800 (PST) X-Google-Original-Date: Thu, 08 Dec 2022 12:21:12 PST (-0800) Subject: Re: [PATCH] RISC-V: Produce better code with complex constants [PR95632] [PR106602] In-Reply-To: <1953155e-7d64-664b-4b88-2fc4cb33acf7@gmail.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.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,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: On Thu, 08 Dec 2022 10:15:47 PST (-0800), gcc-patches@gcc.gnu.org wrote: > > > On 12/8/22 10:53, Palmer Dabbelt wrote: >> On Wed, 07 Dec 2022 12:55:17 PST (-0800), rzinsly@ventanamicro.com wrote: >>> Due to RISC-V limitations on operations with big constants combine >>> is failing to match such operations and is not being able to >>> produce optimal code as it keeps splitting them. By pretending we >>> can do those operations we can get more opportunities for >>> simplification of surrounding instructions. >> >> I saw Jeff's comments.  This is always the kind of thing that worries >> me: we're essentially lying to the optimizer in order to trick it into >> generating better code, which might just make it generate worse code. >> It's always easy to see a small example that improves, but those could >> be wiped out by secondary effects in real code.  So I'd usually want to >> have some benchmarking for a patch like this. >> >> That said, if this is just the standard way of doing things then maybe >> it's just fine? > Bridge combiner patterns are pretty standard. The insn's condition of > cse_not_expected is also in there to minimize the potential for > surprises by not exposing this too early. OK, I'm fine with this, then -- aside from the fairly minor issues pointed out.