From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) by sourceware.org (Postfix) with ESMTPS id F03123858C98 for ; Fri, 22 Mar 2024 08:47:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F03123858C98 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 F03123858C98 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::135 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711097243; cv=none; b=CmdQwbS/j/w6PLBinJMTePtengYVwraSu12tAKxRhRyccH3IdHkIdHC3msUf7yWNRH5GPtKwt8ivg18ryN2AKgGgb96mDCPtilOvlpv92kEVSj+V/PVW6SHNTT6uGTEyVB2AXUARKWJ3apJqcOHFOnVBZIcc3Er5Bt816lBy5Xg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711097243; c=relaxed/simple; bh=tjt2zcxntJc6jl1R6jeISEKnqcHNf9I0afnWC8IciMk=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=Oba/mfEUnT1yZTsNFiNXjmSnepe/17dQIFUQZyZ2n8lGUVA2iXrDVSmejO2/Ci4GrQm3ffQRYILBaVbwcsbEvagonjEPDA/xpld/x8x8nZsFBar7G4j0Yog0HUFk01azWIqz0YJpE7pEb85Z/cYSrQfIxCVIznoG8aAcdzUWFto= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-5148ea935b8so2126707e87.1 for ; Fri, 22 Mar 2024 01:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711097232; x=1711702032; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=fIkZf2ZS7RQBcxw+jxgp36O+paYDgEGXVbGJFOmHMcU=; b=R8EqmqdBwTvseSLlHXq9Z1rwgc66KF2ndOuOfZrooZJ8VdKRrfYDq4rlQKvTFC1NeK IH6HgmjDaKfPzIg2XkkIRkfh4r4Hki6LE9tDCgMzAi/nuA60RZRJyqcoOck7rPxNYZiH +9H9HY7kbQOr94oVfe3Kkd5xcnIlch8sQsqwdXAvNCrMlmffqsbPm+qHnfh5shnq0SxH /MrAROigFWkyCCzBowVmbTwiIlqBplik+8pdpXvxK5Pzb0nMG1jdFWevnZKXaU0fB2iT zlmcxt+VfNCu1i+jQo1p+QweiV3mIKHmiXfwpWwpiw+qjBIdGiXn6ILciIATiNK45soW obTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711097232; x=1711702032; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fIkZf2ZS7RQBcxw+jxgp36O+paYDgEGXVbGJFOmHMcU=; b=vKggLvYMRHfch6lrZuIKmMFvfSNZuj+rnxdiSHbWQ1gaQrzJ3Nm0cO566uHf/L2eZg ac+fYczeQuuyRZMdiH2RjAd6BMdoMObjy8jZffGTZnDUStz9q7/WrnWG6Ieq7uWDsS5K ao9yN2GhMNcrMQDfQFE38Jbaez9r9X510475kK1sGjV4vtW+YJs5tvSHoav4tLUDqh23 gNrwam1Jl6VVoGa8SwMkL3mVdcswjuTG2uAp9GFVH1ogG1r/lpYDrIrKnrkSX56F3IRu KPhmCRud9q2RQPRvVtXR4V+QzyKIx3tr4BkBwGtx+x/+RLaqCGEqa10hqMpYJJYXn0cq BWlg== X-Forwarded-Encrypted: i=1; AJvYcCUPa/chi7JpUdO5dqEmDqtaCZ9R0ZyDWs9lpiUFZ+lwM76bC8UQXbpYz04d0USW0kvFYV6NExGsnkxknyvX3t47vQ09RRf67g== X-Gm-Message-State: AOJu0YwH38KXHIqypNSrZW3gO1OIdbpXniT2vHg4LqWT70/NCZ8ywx3w E3OZJPKiADK2ZNgf879Nk05bI2CIlHDbvyHJZ7xpez8r2wqAfJTa1zcu4Y5TBQgtYfFPiE7R9GK n0dTcswUbNYl66ZMinkOKO5AxNKGgabor X-Google-Smtp-Source: AGHT+IH13XoUlNkcx4Gf/9ovijC/d3Hkhtv45FDQsREXdNdmIcrv2iCUp9uVpoYQWTEdabjAp1WyjTM40Fx+3/+iVXE= X-Received: by 2002:ac2:54ae:0:b0:513:c85e:2848 with SMTP id w14-20020ac254ae000000b00513c85e2848mr1195086lfk.34.1711097232169; Fri, 22 Mar 2024 01:47:12 -0700 (PDT) MIME-Version: 1.0 References: <20240316173524.1147760-1-vineetg@rivosinc.com> <2acab452-4dc0-4782-aedf-8495d84d7374@rivosinc.com> <3faf0264-7b82-4574-bb45-df66d77421be@gmail.com> <899c3e8b-3d0e-48ee-99d7-6f5edfdbb59a@gmail.com> In-Reply-To: <899c3e8b-3d0e-48ee-99d7-6f5edfdbb59a@gmail.com> From: Richard Biener Date: Fri, 22 Mar 2024 09:47:00 +0100 Message-ID: Subject: Re: scheduler queue flush (was Re: [gcc-15 0/3] RISC-V improve stack/array access by constant mat tweak) To: Jeff Law Cc: Vineet Gupta , gcc-patches@gcc.gnu.org, kito.cheng@gmail.com, Palmer Dabbelt , gnu-toolchain@rivosinc.com, Robin Dapp Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.4 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 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, Mar 21, 2024 at 8:56=E2=80=AFPM Jeff Law wr= ote: > > > > On 3/21/24 11:19 AM, Vineet Gupta wrote: > > >> > >> 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 > Now we're getting somewhere. That's in line with expectations. > > I would strongly suspect it's -fno-schedule-insns rather than > -fno-schedule-insns2. The former turns off scheduling before register > allocation, the second turns it off after register allocation. So if > our theory about spilling is correct, then it must be the first since > the second won't affect register allocation. While I can speculate > about other potential scheduler impacts, spilling due to sched1's > actions is by far the most likely. Another option is to enable -fsched-pressure which should help with this issue. > Given the magnitude here, I would bet we can see this pretty clearly if > you've got function level or block level count data for those runs. I'd > start with that, ideally narrowing things down to a function or hot loop > within a function which shows a huge delta. > > From that we can then look at the IRA and LRA dumps and correlate what > we see there with the before/after scheduling dumps to see how we've > lengthened lifetimes in critical locations. > > I'd probably start with the IRA dump. It's going to have annotations in > its dump output like "Potential Spill" which may guide us. In simplest > terms a pseudo is trivially allocatable when it has fewer neighbors in > the conflict graph than available hard registers. If it has more > neighbors in the conflict graph than available hard registers, then it's > potentially going to be spilled -- we can't know during this phase of > allocation. > > As we pop registers off the coloring stack, some neighbors of the pseudo > in question may end up allocated into the same hard register. That can > sometimes result in a hard register being available. It might be easier > to see with a graph > > a--b--c > | > d > > Where a..d are pseudo registers. If two pseudos are connected by an > edge, then they have overlapping lifetimes and can't be allocated to the > same hard register. So as we can see b conflicts with a, c & d. If we > only have two hard registers, then b is not trivially colorable and will > be marked as a potential spill. > > During coloring we may end up allocating a, c & d to the same hard > register (they don't conflict, so its safe). If that happens, then > there would be a register available for b. > > Anyway, that should explain why b would be marked as a potential spill > and how it might end up getting a hard register anyway. > > The hope is we can see the potential spills increasing. At which point > we can walk backwards to sched1 and dive into its scheduling decisions. > > Jeff