From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) by sourceware.org (Postfix) with ESMTPS id 7CE1F3858D28 for ; Thu, 21 Mar 2024 17:25:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7CE1F3858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7CE1F3858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::32b ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711041953; cv=none; b=dgTHnYMrYXXM1M2v3xnA/xJ/7IEth/rWTKmDGx4uCNu2wWQjcrOc25Zc2I8OjaLudWv98W9S8ZnqhDL6nYYE0rIO67x1QIQ3fHJtqc9jfILGJb+/hDUh0JE/vfy6T9tXP12Ts0wxaf9F43YSVPAQQj7wKUMHLUOEIg75w0Ea6EM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711041953; c=relaxed/simple; bh=fK3GSLQgijs71K+m0nGoMQC3viqsgHhfMdigzUJj1mc=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=LeZfiPkIUgDBlvnKUCkVe1mrW53RWCgaEVOQNlsYhIP4WfBIhdo2a3jnf0NaWGfyDdFz1RyfSzwEJNQBWTiG5I8puLqLHc/rqMgqOOk/emcBA61Ibq9svF2tuUW5C7YHAL2RC4vPt88ABCFUqRDFQn6R1f0efF4Dvdsal6IU7Y0= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ot1-x32b.google.com with SMTP id 46e09a7af769-6e67cf739d0so651548a34.1 for ; Thu, 21 Mar 2024 10:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1711041949; x=1711646749; 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=IV9q7r7UwrtSB1ZEi1HSBmB/CK/084ksI21vGfsloTw=; b=k5oEezAp6HPj7V7tosbDfmRptjd5NukyYV/6tezDMi2nYa1X+v4Ny1HVLoPAwO80NJ 5uIvVv+NHCGtYsRXp5cRosX78jabB0CmK9NqeqRn3EuDScDl/dOkfwjnH2zQkyUcnnSe Hg6V4EuYOi9eIZ/Bzan7g2q9Mdf5TcJ8xYuw4vDKl4tS8wGWbTDVJCVevUHU+8u0pT5O hn6vrnmeh6JHnkxNAGUF2v8SmX7yaqL9XG52eFh5WEdoEJ6yirEzB+quD6wgrrbk+bkR NK0P4DyezLGBYBfhxfOe8bEHkAAL14g///SetnXkd6mV0stiVXyodvRZKL1ROOYNfzkN JUDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711041950; x=1711646750; 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=IV9q7r7UwrtSB1ZEi1HSBmB/CK/084ksI21vGfsloTw=; b=CAUEXcenBHH/Zqreb4A/8NBjhFmptUHSygbgqukgPVxaFrKgjERRGAutLPhGEEdOWp y8oR9l6hzWcXurxK5Oe0n2xzB5HnY4ui5WYD1IoXFTfLJrp+K2TsTBjcutNQkNEAyfB/ IKKR82YgJmL6JTcsaoSWeKKP+8f5L0ubuSgDpkqaQDLOPo8ETnzAgFETBtCKLOAsNNvW 0Lnd3ZH83sJ6h5c1dJe3b7piy3EvS6gHF5zC6KSjDqVF6iZKUtNddGZ0B+UVJsRSvZ/t HtmuWJxGvrvqN/vvrL2peOlabpX+vSX9rHCkQ2DXihg7jdnprm/lRizeNbFKWIOoTZl8 GoTA== X-Forwarded-Encrypted: i=1; AJvYcCUf1mMbwVCxIvXH+kfH7Ukh72xy9nwbpCb1URbhQz6jxEvcdFnRBLTCfeu4g0rOv9e9/5p8XBGGTDDHFvXrPPJ+PmOtP0DFDQ== X-Gm-Message-State: AOJu0YyMijal0dZzYsYXGvkayj3l9in8X15xq1hK5xLlyi7yRSjwvJGo Y9sgLRpfC2VwO+A3wsTeykreJUa9IVoMenqO11AlQ06al6T+sH5Mo6kqgYMBtYOyV6DHR0pM/Du L X-Google-Smtp-Source: AGHT+IFacKrK6SjfC/HWxnv2qfEYE1IHbDQ0vamAC07i/TWhvjfAtduLQbOdLfRciubyBIq1z0STTg== X-Received: by 2002:a05:6a20:841c:b0:1a3:71d4:cf3 with SMTP id c28-20020a056a20841c00b001a371d40cf3mr119696pzd.59.1711041555947; Thu, 21 Mar 2024 10:19:15 -0700 (PDT) Received: from [10.0.16.165] ([12.44.203.122]) by smtp.gmail.com with ESMTPSA id p13-20020a056a0026cd00b006e672b48b49sm70663pfw.157.2024.03.21.10.19.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Mar 2024 10:19:15 -0700 (PDT) Message-ID: Date: Thu, 21 Mar 2024 10:19:14 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: scheduler queue flush (was Re: [gcc-15 0/3] RISC-V improve stack/array access by constant mat tweak) Content-Language: en-US To: Jeff Law , gcc-patches@gcc.gnu.org Cc: kito.cheng@gmail.com, Palmer Dabbelt , gnu-toolchain@rivosinc.com, Robin Dapp References: <20240316173524.1147760-1-vineetg@rivosinc.com> <2acab452-4dc0-4782-aedf-8495d84d7374@rivosinc.com> <3faf0264-7b82-4574-bb45-df66d77421be@gmail.com> From: Vineet Gupta In-Reply-To: <3faf0264-7b82-4574-bb45-df66d77421be@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.9 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 3/21/24 07:45, Jeff Law wrote: >>>> The first patch is the main change which improves SPEC cactu by 10%. >>> Just to confirm. Yup, 10% reduction in icounts and about a 3.5% >>> improvement in cycles on our target. Which is great! >>> >>> This also makes me wonder if cactu is the benchmark that was sensitive >>> to flushing the pending queue in the scheduler. Jivan's data would tend >>> to indicate that is the case as several routines seem to flush the >>> pending queue often. In particular: >>> >>> ML_BSSN_RHS_Body >>> ML_BSSN_Advect_Body >>> ML_BSSN_constraints_Body >>> >>> All have a high number of dynamic instructions as well as lots of >>> flushes of the pending queue. >>> >>> Vineet, you might want to look and see if cranking up the >>> max-pending-list-length parameter helps drive down spilling. I think >>> it's default value is 32 insns. I've seen it cranked up to 128 and 256 >>> insns without significant ill effects on compile time. >>> >>> My recollection (it's been like 3 years) of the key loop was that it had >>> a few hundred instructions and we'd flush the pending list about 50 >>> cycles into the loop as there just wasn't enough issue bandwidth to the >>> FP units to dispatch all the FP instructions as their inputs became >>> ready. So you'd be looking for flushes in a big loop. >> Here are the results for Cactu on top of the new splitter changes: >> >> default : 2,565,319,368,591 >> 128 : 2,509,741,035,068 >> 256 : 2,527,817,813,612 >> >> I've haven't probed deeper in generated code itself but likely to be >> helping with spilling > Actually, I read that as not important for this issue. While it is 50b > instructions, I would be looking for something that had perhaps an order > of magnitude bigger impact. Ultimately I think it means we still > don't have a good handle on what's causing the spilling. Oh well. > > So if we go back to Robin's observation that scheduling dramatically > increases the instruction count, perhaps we try a run with > -fno-schedule-insns -fno-schedule-insns2 and see how the instruction > counts compare. Oh yeah ! Robin hinted to this in Tues patchworks meeting too default : 2,565,319,368,591 128 : 2,509,741,035,068 256 : 2,527,817,813,612 no-sched{,2}: 1,295,520,567,376 -Vineet