From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by sourceware.org (Postfix) with ESMTPS id A84E73857736 for ; Tue, 23 Jan 2024 21:12:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A84E73857736 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 A84E73857736 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::535 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706044364; cv=none; b=UhFo1cM0eZGORrfjO1OET3xYu6TcyraSSMDj4bIMBSNwnvKXaeZCow/y3/3TT5+DV6NwjOBicDjPu4C7aWPLncej/kKw1uyx20uAbmylmozpcxgPXfWRxllZMLRiMK1TOVddw7ocMouI0Iu2vB8AoVRcNBp5sSIxrL68MGH4UCQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706044364; c=relaxed/simple; bh=HgKPnDDVMZa6bloTAnkK/GvOEkbNcjQxMyTcTGPjV6M=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=tJOdLT6U/yVN8Kp4g+G8rp5PBb4M8slbDi48xCXl+OMvXJmgbtE80mDowQ2HFcelUWR+viMXu4bdE0cTZFGz0MusrUR/CVE1oxhYFSQzyxsmw8lvF8piDxaCzK56Do00gz8YP2SCcy/gs9NBvbCHHNLFtICWerR9dhBJepcE0hU= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-55ad2a47b7aso3890242a12.3 for ; Tue, 23 Jan 2024 13:12:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706044361; x=1706649161; darn=gcc.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=75vsw4THjyoMzvyrHW8S+D916y2ba55c8cfXWCkuBxY=; b=TjFJN33sEBPk7T+RBUgnJsGDCu6KEh5aHJzHBPZlG2iEAfp3j8oAnV3AoAd6j+aazM WgPNuxjcKQyOSUBygb1V7TY0OwsBlvfKve7e7EubecmBV5k0imEtOzTwo0bwStai4HEC 07+ZocVgsoBsdzA85favhu32KcjgiSUQLR1G5xL19XMgJWEeguc1athNCy9zPHk5xMVq Zy67hOK7A61KmUvUg8aZpukP9mIa4mfKn0BOJmn1PP/3LQSBXP8gF2PsVsFNni+UCfUw l9RJqKvfRbkCoRMZJRgOuiSsEm7vRadA1gNZp5WF9NMBLfIva0gdFfWbht7YpL5660CL hrfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706044361; x=1706649161; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=75vsw4THjyoMzvyrHW8S+D916y2ba55c8cfXWCkuBxY=; b=bT3HIX+QRtBxVYQYsjuGNTKS01Ib5qrwzYIdWqTsrFJALes8EoESD6plsZYbxGq1s3 dhvv95KnRBolrh9a24B+voML4MtBAOALnlCWShX3PmENbhnCBSfME+3fucfmyjji/rhD 8ITC/WZ7EG5yjDNul9be5SwFmkP6+2Q7YVQPOGWUaMJxKNQaEHSxXLE2KV5QtDWcmAML LL8gK98GtEUKroWx3VYAipjG7lzGXg+dtYiWjy2RHagob5K1xjYkW8Z8ohhx2uByJbsL yYTXXsd/xAAwjxZm3FaX7vY0WdTZY7rj1RVxfcfEx4oshXVuYxPFEvJ5xJGXWmwjYO6l Z3wg== X-Gm-Message-State: AOJu0YwtRqlRNPCOoxE1sMGHhfWPXprYbuYWMD3m670vtrt/3T19BdEm pDKbUFOel37DqY/oYt6XswhSNHciIUHeyOBDxMAUy1EjPhd4GQQY7qin/3Td X-Google-Smtp-Source: AGHT+IH8p83RrbGnIMqLLiKDeGNF7ElXf0ZbyeEwKbt+Nx2+e7aPBgzjp6euumKAazBaePNpvCwMTw== X-Received: by 2002:aa7:c396:0:b0:55a:5c28:b2e8 with SMTP id k22-20020aa7c396000000b0055a5c28b2e8mr767501edq.44.1706044361034; Tue, 23 Jan 2024 13:12:41 -0800 (PST) Received: from [192.168.1.24] (ip-149-172-150-237.um42.pools.vodafone-ip.de. [149.172.150.237]) by smtp.gmail.com with ESMTPSA id y6-20020a056402134600b0055c46f452c2sm2458248edw.65.2024.01.23.13.12.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Jan 2024 13:12:40 -0800 (PST) Message-ID: Date: Tue, 23 Jan 2024 22:12:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: rdapp.gcc@gmail.com, kito.cheng@gmail.com, kito.cheng@sifive.com, jeffreyalaw@gmail.com Subject: Re: [PATCH] RISC-V: Fix large memory usage of VSETVL PASS [PR113495] Content-Language: en-US To: Juzhe-Zhong , gcc-patches@gcc.gnu.org References: <20240123101249.2706615-1-juzhe.zhong@rivai.ai> From: Robin Dapp In-Reply-To: <20240123101249.2706615-1-juzhe.zhong@rivai.ai> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.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,T_SCC_BODY_TEXT_LINE 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: > SPEC 2017 wrf benchmark expose unreasonble memory usage of VSETVL PASS > that is, VSETVL PASS consume over 33 GB memory which make use impossible > to compile SPEC 2017 wrf in a laptop. > > The root cause is wasting-memory variables: LGTM. The new code matches compute_lcm_local_properties more closely which makes sense to me. One separate thing, nothing to do with this patch - I find bitmap_union_of_preds_with_entry not wrong but weirdly written. Probably because it was copied from somewhere and slightly adjusted? If you touch more code anyway, would you mind fixing it? for (ix = 0; ix < EDGE_COUNT (b->preds); ix++) { e = EDGE_PRED (b, ix); bitmap_copy (dst, src[e->src->index]); break; } if (ix == EDGE_COUNT (b->preds)) bitmap_clear (dst); The whole idea seems to _not_ skip the entry block. So something like if (EDGE_COUNT () == 0) {...} else { bitmap_copy (...)) should be sufficient? If the input is assumed to be empty we could even skip the copy. > -/* { dg-options "--param=riscv-autovec-preference=scalable -march=rv32gcv -mabi=ilp32 -fno-schedule-insns -fno-schedule-insns2 -fno-tree-vectorize" } */ > +/* { dg-options "--param=riscv-autovec-preference=scalable -march=rv32gcv -mabi=ilp32 -fno-tree-vectorize" } */ Why that change? Was no-schedule necessary before and is not anymore? Is it a result from the changes? I'd hope not. Regards Robin