From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) by sourceware.org (Postfix) with ESMTPS id EC27F3865479 for ; Wed, 15 May 2024 09:37:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EC27F3865479 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 EC27F3865479 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::b32 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715765883; cv=none; b=UCgM/pyv+TMoTHgY1wNHStFYt0ekLOLEqa9ZpVuAz57n3WSNcEGxdIcBtuVS0IdxEmuw26kZnVeG6fgr65s6Y/nu6SZWuTk72Jo+4AC98FFK6k7g8PfuEeO3Pe4mshw2m9/wbO+QPvPs0qcJRA3Izm8IOM/a0AUqYK9sGIl1oT4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715765883; c=relaxed/simple; bh=Aw6WT9DJQNn8RQEnWsIlEir23kXd0VR9+5tfAP6aqUM=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=MudR+ZGaTKhKskNQDmH7kMP5EhheHy3sodHX0EVHCN6Osdco0uu6ytB0qJbZJPviJLiZar5vRtAJDyFa/glWfH9uvjnjOSwiylmQ3fUWwL0OCTU6zvm7PXZiqmlIYfkNFCy9f1F3081oBtRNNeBPuxV8yUdB7Ew4dsgX8lRqL3o= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-yb1-xb32.google.com with SMTP id 3f1490d57ef6-de46b113a5dso6342586276.3 for ; Wed, 15 May 2024 02:37:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715765879; x=1716370679; darn=gcc.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=lATrAuZ36Slv/ah0bvAVuQXVE8Ht3YnK94PvCE/VqCo=; b=WZD6d/XvpT0d5LlRi0gy7r+NL3kGusIPeZGWfW9RmdaHHdQa6LvyjynzSdeIJitqs9 A8nlCdCvevtRtYG93jEWYdzUSRfzKaVdydTXJ2whcywRS/FTKt5K985HrgqJGJlH5az/ wvmjQgJEvVFRKIt2W48TJlnIY+k7/nC3eQ8HFzj+m5+JSr7qSPUeK9qGfqDCYa7zOVnH kamHEOT/N9Nrk7q4Tzzn1ggVizGcsrtHGG6gV97DcdalNjLQuVEGImvDpaz4rkyznx73 nsuM46PYFWAG4JZvpwa//ROn8xoJrG8ypGWtyt6qcYSRyKmrGRPl1hnyVt6att9k02Ni tBmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715765879; x=1716370679; h=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=lATrAuZ36Slv/ah0bvAVuQXVE8Ht3YnK94PvCE/VqCo=; b=uk2nzWbopwco6dIsS1P8bNj7Xy37cpUvUSjC36JS9pK5OlHkfWKPE/Z0UI4tcNIZ30 +S/2P5SpNieMdMeJ4RAfL317he4zpuVQpttKkPDki1qvHRp4sd+OurvdjrhX2krScwJo U0sIXBXEsF2UXv18oj/aFgygrGSA5gbzvIVjJP4TvYcyQssGglPXAoLSm/N7UEyBe3US LaRCGmAHtr6ly4mgeub+EM5PggIpEySOdSzOxILnE8JQjYyqdT46heLxYhPq2gpkNX+/ MEge8CpNv4cq94lJVrFkE+9WKotGN4P9fBKpvMKoUJgeptIgGqVQkAsTl7Z0tgLkNNg/ iSIw== X-Forwarded-Encrypted: i=1; AJvYcCVtB7Ox/z8bKdOE9lbTtd/DANe9usvarms2zheNI/gXt1oAMO9cb3BXUCroEdoroZEE5/yBkrH+8mHZnSza9zRYRuiX4BJ37Q== X-Gm-Message-State: AOJu0Yy1pT+aDadM7yiaofWLTMfqvZh+1uaPbJFRM441J3wLZZUK+NVs SsyvATzhozEyNsxt/EEijPFCC743k5lUd0026Aqr1VV5y6ubkNDMwPj7aK5f711QbqtuGhM94Yc E4wAyPPXPU/eEJ4IfpIZy+EudKXc= X-Google-Smtp-Source: AGHT+IHSAyAYS4IjchXC/h+m4bBwI5W4STCpm01O9UeYqiVQ8144+M8jmuZasYfOqnmS8F/hjZmFwxgitu/TxLHUi1w= X-Received: by 2002:a25:2fca:0:b0:dcf:f9bd:fe05 with SMTP id 3f1490d57ef6-dee4f360473mr14331861276.48.1715765878934; Wed, 15 May 2024 02:37:58 -0700 (PDT) MIME-Version: 1.0 References: <20240513022737.3105192-1-hongtao.liu@intel.com> In-Reply-To: From: Hongtao Liu Date: Wed, 15 May 2024 17:49:29 +0800 Message-ID: Subject: Re: [PATCH] Don't reduce estimated unrolled size for innermost loop. To: Richard Biener Cc: liuhongt , gcc-patches@gcc.gnu.org, Jan Hubicka Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 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: C -std=gnu++14 LP64 note (test for > > > > g++warnings, line 56) > > > > g++: g++.dg/warn/Warray-bounds-20.C -std=gnu++14 note (test for > > > > g++warnings, line 66) > > > > g++: g++.dg/warn/Warray-bounds-20.C -std=gnu++17 LP64 note (test for > > > > g++warnings, line 56) > > > > g++: g++.dg/warn/Warray-bounds-20.C -std=gnu++17 note (test for > > > > g++warnings, line 66) > > > > g++: g++.dg/warn/Warray-bounds-20.C -std=gnu++20 LP64 note (test for > > > > g++warnings, line 56) > > > > g++: g++.dg/warn/Warray-bounds-20.C -std=gnu++20 note (test for > > > > g++warnings, line 66) > > > > g++: g++.dg/warn/Warray-bounds-20.C -std=gnu++98 LP64 note (test for > > > > g++warnings, line 56) > > > > g++: g++.dg/warn/Warray-bounds-20.C -std=gnu++98 note (test for > > > > g++warnings, line 66) > > This seems to expect unrolling for an init loop rolling 1 times. I don't > see 1/3 of the stmts vanishing but it's definitely an interesting corner > case. That's why I was thinking of maybe adding a --param specifying > an absolute growth we consider "no growth" - but of course that's > ugly as well but it would cover these small loops. > > How do the sizes play out here after your change? Before it's > > size: 13-3, last_iteration: 2-2 > Loop size: 13 > Estimated size after unrolling: 13 After: size: 13-3, last_iteration: 2-2 Loop size: 13 Estimated size after unrolling: 20 Not unrolling loop 1: size would grow. > > and the init is quite complex with virtual pointer inits. We do have > > size: 1 _14 = _5 + -1; > Induction variable computation will be folded away. > size: 1 _15 = _4 + 40; > BB: 3, after_exit: 1 > > where we don't realize the + 40 of _15 will be folded into the dereferences > but that would only subtract 1. > > size: 3 C::C (_23, &MEM [(void *)&_ZTT2D1 + 48B]); > > that's the biggest cost. > > To diagnose the array bound issue we rely on early unrolling since we avoid > -Warray-bounds after late unrolling due to false positives. > > This is definitely not an unrolling that preserves code size. > > > gcc: gcc.dg/Warray-bounds-68.c (test for warnings, line 18) > > > > gcc: gcc.dg/graphite/interchange-8.c execution test > > An execute fail is bad ... can we avoid this (but file a bugreport!) when It's PR115101 > placing #pragma GCC unroll before the innermost loop? We should > probably honor that in early unrolling (not sure if we do). > > > gcc: gcc.dg/tree-prof/update-cunroll-2.c scan-tree-dump-not optimized > > "Invalid sum" > > > > gcc: gcc.dg/tree-ssa/cunroll-1.c scan-tree-dump cunrolli "Last > > iteration exit edge was proved true." > > > > gcc: gcc.dg/tree-ssa/cunroll-1.c scan-tree-dump cunrolli "loop with 2 > > iterations completely unrolled" > > again the current estimate is the same before/after unrolling, here > we expect to retain one compare & branch. > > > gcc: gcc.dg/tree-ssa/dump-6.c scan-tree-dump store-merging "MEM > > \\[\\(char \\*\\)\\&a8] = " > > > > gcc: gcc.dg/tree-ssa/loop-36.c scan-tree-dump-not dce3 "c.array" > > again the 2/3 scaling is difficult to warrant. The goal of the early unrolling > pass was abstraction penalty removal which works for low trip-count loops. > So maybe that new --param for allowed growth should scale but instead > of scaling by the loop size as 2/3 does it should scale by the number of > times we peel which means offsetting the body size estimate by a constant. > > Honza? Any idea how to go forward here? > > Thanks, > Richard. > > > gcc: gcc.dg/tree-ssa/ssa-dom-cse-5.c scan-tree-dump-times dom2 "return 3;" 1 > > > > gcc: gcc.dg/tree-ssa/update-cunroll.c scan-tree-dump-times optimized > > "Invalid sum" 0 > > > > gcc: gcc.dg/tree-ssa/vrp88.c scan-tree-dump vrp1 "Folded into: if.*" > > > > gcc: gcc.dg/vect/no-vfa-vect-dv-2.c scan-tree-dump-times vect > > "vectorized 3 loops" 1 > > > > > > > > If we need some extra leeway for UL_NO_GROWTH for what we expect > > > to unroll it might be better to add sth like --param > > > nogrowth-completely-peeled-insns > > > specifying a fixed surplus size? Or we need to look at what's the problem > > > with the testcases regressing or the one you are trying to fix. > > > > > > I did experiment with better estimating cleanup done at some point > > > (see attached), > > > but didn't get to finishing that (and as said, as we're running VN on the result > > > we'd ideally do that as part of the estimation somehow). > > > > > > Richard. > > > > > > > + unr_insns = unr_insns * 2 / 3; > > > > + > > > > if (unr_insns <= 0) > > > > unr_insns = 1; > > > > > > > > @@ -837,7 +847,7 @@ try_unroll_loop_completely (class loop *loop, > > > > > > > > unsigned HOST_WIDE_INT ninsns = size.overall; > > > > unsigned HOST_WIDE_INT unr_insns > > > > - = estimated_unrolled_size (&size, n_unroll); > > > > + = estimated_unrolled_size (&size, n_unroll, ul, loop); > > > > if (dump_file && (dump_flags & TDF_DETAILS)) > > > > { > > > > fprintf (dump_file, " Loop size: %d\n", (int) ninsns); > > > > -- > > > > 2.31.1 > > > > > > > > > > > > -- > > BR, > > Hongtao -- BR, Hongtao